Some interesting arguments have been brought up in the discussion. Let's see:
Now instead of solving that by fixing what's being exploited, they want to remove the OP_RETURN standard limit entirely to try and encourage the abusers to use what could be more expensive![..]
After that "fix" you'll have 2 problems!
As I've already written before, "fixing what's being exploited", is simply not possible. You would direct the same spam into potentially more harmful mechanics.
But let me explain why I don't believe that the OP_RETURN limit lift would cause additional trouble, so there are no "two problems".
As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation. The market these people are addressing is however limited. There is only X demand for NFTs on the Bitcoin blockchain (a sub-market of the bigger NFT market).
Thus there will be most likely no additional market being created only by liberating OP_RETURN (see also below to my answer to @jaybny). But there is a positive effect: demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels. And I think most of us here agree that OP_RETURN is the least harmful "channel" of these three.
the fact that nodes do not have a say in what they relay.
I'm also a bit in conflict with this part of the PR, even if I (as I wrote above) also understand the arguments in favour of removing that possibility mentioned by @gmaxwell.
I also want to point out that if the datacarriersize parameter is removed, then the incentive to use alternative implementations like Knots could increase. This would create additional complexity: Now both versions are in conflict regarding a relatively minor issue like standardness. But in the future it's possible that alternative implementations, encouraged by increased use, could move towards protocol changes, like the reduction of block size to something like 150 kB proposed by the Knots main developer.
Regarding this issue I'm moving more towards NACK again.
Technically I think the removal of the parameter makes sense for the reasons gmaxwell mentioned, but
socially it could have unintended negative consequences. For me, both issues should be at least separated cleanly: "lifting the limit for standardness" and "letting nodes decide how much arbitrary data per tx they relay".
Removing the limits all together for no reasons other than "they can do it anyways", creates a negative game theory incentive. Where "honest actors", those that do want to follow the social consensus and ethos of bitcoin as p2p money vs a data availability layer, now have the green light, that the social consensus of bitcoin is to use it as an immutable database.
While I think your argument is interesting, I think it's highly speculative.
First, we can't assume that "everything what is possible with Bitcoin is covered by the social consensus". Now, for example, the Taproot witness "exploit" is also possible, and there is no consensus to limit it, so according to your assumption, the "social consensus" is that it is "allowed" and "legitimate". Even if hundreds of pages of discussions in this forum and elsewhere speak otherwise.
Thus I think the removal of the limit would instead generate a "message" like: "social consensus is that OP_RETURN is the least harmful of the three methods to include arbitrary data on chain, so if you want to include them, this is
at least not more limited than the other two." (it isn't even the "preferred" method, due to the witness discount one can assume that the preferred metod is still Taproot).
Second, what I wrote above about the limited market for NFTs and tokens would also affect the game theory for additional protocols which may be developed on top of OP_RETURN. If there is no additional demand, then the "social consensus" doesn't really matter, because nobody would waste fees for additional data transactions (be it with NFTs, tokens or whatever). Imo thus there is no additional incentive for the development of data-heavy protocols because other methods exist anyway.