Even if it were implemented, it would create a mess if some nodes pruned a transaction while others did not. Also, the inputs of fully pruned transactions could be double spent.
Nah, see, the whole point of OP_RETURN is that unless you're bootstrapping new clients you don't actually need to store it. If pruning is implemented, you're not pruning the transaction - you're pruning the
output. The coins that were used as inputs are still used up in your local state.
Of course, that's easiest when you're taking the approach of using the blockchain for bootstrapping only, and just using the UTXO set for day to day transactions. If you want to store the blockchain too, you need some extra mechanism if you want to support redacting OP_RETURN data blocks. You could theoretically do it with ZKPs, though - basically attaching a proof that "for transaction X, I blotted out their data, but I totally know an input that still makes that transaction hash to its txid".
All that said, though, I feel like we should cross this bridge when we come to it. Sound technical solutions exist, at least once you decide that you want to delete a particular OP_RETURN output. But there's no point in implementing them if this is still just a theoretical attack.
The OP should consider that his computer contains a sufficient amount of '1's and '0's which could all be simply rearranged somewhat to form 1000s of child porn images - ON HIS COMPUTER. But those '1's and '0's on his computer, just because they are presently out of order, nevertheless do constitute child porn. He is clearly a pig. That is right, your computer is loaded with child porn!!! The cops are going to find you and arrest you for this and you will go to jail for life.
That's a little disingenuous. OP_RETURN data blocks are opaque binary data, and every image in a commonly used image format begins with a preamble that in practice make the interpretation of the blob pretty unambiguous.