We have already discussed this in the thread, but there is also a pull request which removes the default limitation for OP_RETURN  (i.e. these are only limited the max transaction size) do not remove the datacarriersize parameter. The nodes then could continue to "vote". (It's also not really a vote, it only affects the own node's behavior.)

But this pull request had about the same level of disapproval of the original one. Which is a bit disappointing, because it shows that the opposers aren't really concerned with the nodes' choices to configure their nodes like they want. Instead, they want to preserve restriction of the least harmful method to store data (OP_RETURN), but they seem to be still totally okay with spam instead stuffed into fake public keys (e.g. Bitcoin Stamps) which spam not only the blockchain but also the UTXO set.

I believe also that there are only very few Core devs which really are "pro-spam" or which do not care about blockchain congestion (read the mailing list discussion for more about that, there's literally nobody argumenting in favour of things like Ordinals). The intent of the OP_RETURN limit lifting is that Bitcoin users that want to store data, should use a less harmful method than the fake public keys method. So yes, I suggest to hear gmaxwell's advice and read through the first 5 pages of this thread.

Ah, and you mentioned a hard fork, but this is absolutely not possible with the discussed change here, as the OP_RETURN limits are not a part of the Bitcoin protocol. The discussion with @mikeywith touched the topic of hard forks only because we discussed the role of Core devs in Bitcoin's power ecosystem.

@mikeywith: I think I agree with you about the points in your last post.