Yes, but it would be even more inefficient to use op_return, instead you'd put the same crap in the witness data.

Yes, always could have.

No op_return is already not the cheapest way to do this, sticking it in signatures is. However, if for whatever reason you didn't want to use signatures you can emed the data as fake addresses, it's only a little less efficient and isn't non-standard, has never been non-standard, and couldn't be made non-standard (because it's not distinguishable to someone who doesn't have your key)

Yes, this is true and it is unchanged by op_return limits.

No, it makes no difference to that abuse since you wouldn't use op_return anyways.

If it was the way you thought opinions would likely be very different.

It seems fundamentally impossible to block, at most it can and is quite expensive.

The existing countermeasures is the block files and utxo set are encrypted on disk with a key that is unique to each node, so that automated scanning like photo recovery tools, illegal image searching tools, and anti-virus won't turn up anything.  Bitcoin Core also doesn't offer any "random access" to transactions, only whole blocks if you're not pruning-- proposals to add such random access that could turn nodes into image file servers were rejected for explicitly this reason (much to Mike Hearn's outrage). And there is no interface via RPC or GUI to view images or other such data that has been stuffed in, when the data is accessible at all it's only there as hex encoded binary for diagnostics.  These protections have been put in and maintained for years because it was always understood to be a risk of Bitcoin.

I would hope that a competent legal decision would look at the facts and say that one someone has snuck in illegal data secretly by encoding it into transactions, and you don't even know about it and don't have practical means to access it yourself-- that the illegal thing ought to actually be the access *instructions* rather than the blobs.  This issue isn't unique to Bitcoin someone could secretly encode illegal data into all manner of places, advertisements in news papers, the background of public audio recordings, QR codes on busy city walls, encoded into ebook cover art uploaded to Wikipedia [1].  Illegal data could even be disguised into court documents. ... But it is somewhat worse for Bitcoin because in most cases the illegal material could be removed, while in Bitcoin there is both no means to remove anything and no authority that could do it.

It's all a sucky thing, but it is not changed by OP_RETURN because the data would not be encoded via OP_RETURN and if it were for some it would at least be better than using 'fake address' outputs because OP_RETURN is pruned (meaning you can get the data off your systems by using pruning) and doesn't gunk up the UTXO set.  And 'fake address' outputs can't realistically be blocked.

In the long run this will likely end up before courts and hopefully the outcomes will be good.  Though this risk is also part of the reason that there is interest in UTXO based sync, even through accepting a UTXO set is a radical change in the security model it would mean not having to handled old pruned data that might be unlawful.  (and keep in mind OP_RETURN like witness data is pruned, so if there is any objectionable content we strongly prefer it be in the pruned data.  If it is in 'fake addresses', then it's not eliminated by pruning and can't be.


[1] Fun fact: back before Bitcoin was a thing and I was one of the volunteer sysadmins of Wikpedia I discovered that some clever people were unlawfully sharing ebooks by uploading tiny thumbnails of the cover art with an embedded RAR stuck to the end of the image!  The rar decoder would ignore the jpeg and unpack the book.  Sadly I had to end their fun and games.