Fine, I ended up looking into it.
PR 5247 changed the semantics of STRICTENC policy in late 2014 so that during a CHECKMULTISIGVERIFY, if a pubkey with an incorrect prefix is encountered, the script fails. The previous behaviour was that if a pubkey was invalid, the check failed for only that pubkey and processing continued on to the next pubkey.
I still have to go through my IRC logs, but my recollection is there is at least one person who had their funds "soft confiscated" in the sense that they were now, by policy only, unable to spend their UTXOs and would require bypassing policy to retrieve their funds.
People who have better databases than me are welcome to search through bare multisig UTXOs to see if there are any having a strict subset of malformed pubkeys in them.
So one minor correction to my story: it wasn't a matter of the pubkey being off-curve, but rather having an invalid prefix / invalid encoding.
I don't even think bitcoin has ever policy restricted something that was in active use, much less softforked out something like that.
I invite the Bitcore lore experts to correct me here, but I recall someone many years ago finding that their bare multisig funds (likely related to the Counterparty nonsense) were stuck by policy due to some new policy being enacted to mandate that pubkeys in bare multisigs must now all be on-curve points ... or something like that. I do hope that they managed to get their funds recovered by now with direct miner intervention.
I really ought to vet my claim above by going through my IRC logs and Bitcoin development history ... but a quicker way is to post a claim publicly on the internet and wait for someone else to call it out as being wrong.
Also, I think this type of policy change quite harmful and shouldn't be replicated, and ideally reverted, assuming my story is correct.