Honest question, as I understand it OP_RETURN isn't being removed, the OP_RETURN size limit is being removed (is that true?). If so, wasn't OP_RETURN was specifically designed to be easily pruneable? So why wouldn't people just choose to prune OP_RETURNs from their nodes? Then they wouldn't be "hosting" anything that may get in from this change, right?
Discussion
its not the only place to store it, its not even the most economical place to store it
Right, so why would removing the limit matter so much?
It doesn’t, its all lies by knots people to stir up drama.
The only point I agree with them on so far is that I like keeping things configurable for the people who care, even if they change the default. For the record, I run Core and Knots, but I configured my Knots instance to basically allow anything through 😂

In order to validate the block, any node needs to compute the hash of the block and that means you need to download the whole block and compute the hash
That can't be avoided by any node that wishes to validate blocks
After validating a block, you're right that the OP_RETURNs don't need to be stored any more, and you could therefore delete or overwrite that particular data
But, if you want to keep the whole transaction history, in order to be able to see everything, then your options are limited. I guess you can write node software which, after validating the block, will overwrite or delete some data (e.g. OP_RETURNs) that you don't want to keep around
But the more you delete, the more difficult it is to call yourself a full node. For example, you can't help other nodes to join the network
It isn't about storing/pruning unlimited op_returns, it's about relaying that data through the mempool.
Knots:
If I don't want to relay large op_returns I shouldn't have to.
Core:
Relay everything consensus valid