I'm afraid this PR is a lot worse than what it appears at first. It is not just removing the OP_RETURN limit (which is bad enough on its own since bitcoin is not a cloud storage!), but also it is removing the option user had to set/change that limit as well. In other words if this PR is merged and if you run the next version of bitcoin core you will no longer be able to choose which OP_RETURN size you want to relay (that choice should be yours to make), and instead you will be forced to use what the default setting is!
In fact things like this are the reasons why I've argued for the benefits of having a strong alternative implementation of the Bitcoin protocol to be used instead of core... At some point when the core devs keep refusing to fix exploits like what allows the Ordinals Attack to take place and then limit users' ability to set their own standard rules, the benefits of having an alternative implementation outweighs the disadvantages of it...
To be honest, this PR is worse than it first appears it eliminates not only the OP_RETURN size limit, which is already dubious because Bitcoin isn't designed to be a cloud storage service, but also the node operators' ability to set that limit themselves. That is significant until now, the -datacarriersize option allowed users to specify the type of data they wanted to relay. You will have no choice but to accept whatever default Core decides if this PR is merged. A decentralised system shouldn't operate that way
This directly connects to the bigger issue Core developers have demonstrated a lack of willingness to handle spam like attacks (such as Ordinals) and now they are also limiting the options available to node operators to defend against such misuse. For this reason, I've been arguing for some time that we need significant alternative Bitcoin implementations, not just as a backup plan but also as a practical check on Core's centralised decision making.
When relay policy control begins to be restricted and user choice is eliminated, it is an indication that diversity in development is not only beneficial but also necessary