while in Bitcoin there is both no means to remove anything (other than pruning) and no authority that could do it
What about chain reorganization?
And 'fake address' outputs can't realistically be blocked.
If some public key is exposed, then it can be required by consensus rules, to be a valid point on secp256k1. And it is possible to make all outputs spendable in theory, if all coins will always land on valid public keys.
If it is in 'fake addresses', then it's not eliminated by pruning and can't be.
If everything is behind some kind of public key, then things can be combined, while removing in-between data, and preserving the final destination of all coins. Also, if things are behind unique public keys, then they can be sorted, which will block a lot of people from storing meaningful data on-chain (especially if everything is finally baked into one huge transaction per block, and nobody can escape sorting by splitting things into separate transactions).
Also, if you have chain X, with chainwork Y, then if consensus rules encourage you to produce a new version of the chain, where the chainwork is bigger, and things are more compressed in the process, then you can achieve UTXO-based Initial Blockchain Download, where every new version is always covered with more Proof of Work, than the previous one.
In general, I think OP_RETURN limits will be finally lifted, that way or another. But the problem with spam will still be there, and it will be more and more urgent, as the blockchain will contain more and more data. Which means, that nodes will evolve in a way, to make things faster, and to process more proofs, that some data chunks are valid, instead of processing the original data. Because in many cases, you know in advance, how coins will be spent in the future, and you can optimize your node, to store only things, which are strictly required, and prune everything else, by simplifying it with proofs, that everything is valid.
For example: if there are some data pushes, which are not enforced by any consensus rules, then you don't have to store all of that data. You can store only the initialization vector of SHA-256, some initial chunks from the beginning, and some last chunks from the end, and for everything in-between, you can just operate on simplified proofs, that things are correct, as long as SHA-256 is not broken.