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.
Bitcoin doesn't support intra-transaction pruning. It would be possible using a merkle tree of inputs and outputs but currently you can't prune just an output and still validate the transaction. Now you are right we don't use the blockchain to validate new blocks and txns. We use the blockchain to build the UTXO and use the UTXO to validate new txns and blocks. Technically you could delete the entire historical blockchain once you parse it without any reduction in security but that isn't what most people mean when they say prune the blockchain.
An individual could easily delete an OP_RETURN output but with the current chain validation someone, somewhere must record it. You can't validate a txn without all the outputs. You can't validate a block without validating all the transactions. You can't validate the blockchain without validation all the blocks.
Still I think the worry about OP_RETURN misses the point. Bitcoin makes it pretty easy to encode arbitrary data in transactions without using OP_RETURN. Even if OP_RETURN outputs were easily pruned to comply with local laws what about all the other transactions. Right now you can use native multisig to encode up to 192 bytes per output at the cost of just of one satoshi higher than the dust threshold. Honestly I think new non-P2SH outputs should be made invalid at some point in the future not because of illegal activity but because if used for arbitrary data it bloats not just the blockchain but the far more critical UTXO set.