Here is a consensus change proposal by PortlandHODL that attempts to address the OP_RETURN battle.

Proposing: Softfork to after (n) block height; the creation of outpoints with greater than 520 bytes in the ScriptPubkey would be consensus invalid.

This is my gathering of information per BIP 0002

After doing some research into the number of outpoints that would have violated the proposed rule there are exactly 169 outpoints. With only 8 being non OP_RETURN. I think after 15 years and not having discovered use for 'large' ScriptPubkeys; the reward for not invalidating them at the consensus level is lower than the risk of their abuse.

Reasons for

Makes DoS blocks likely impossible to create that would have any sufficient negative impact on the network.

Leaves enough room for hooks long term

Would substantially reduce the divergence between consensus and relay policy

Incredibly little use onchain as evidenced above.

Could possibly reduce codebase complexity. Legacy Script is largely considered a mess though this isn't a complete disablement it should reduce the total surface that is problematic.

Would make it harder to use the ScriptPubkey as a 'large' datacarrier.

Possible UTXO set size bloat reduction.

Reasons Against

Bitcoin could need it in the future? Quantum?

Users could just create more outpoints.

Thoughts?

source of onchain data

Andrew Poelstra responded in favor of the proposal, noting:

Personally, I like this. Unlike restrictions on opcode behavior or witness data, it is impossible for there to be any existing UTXOs which "might turn out to need" scriptpubkeys greater than 520 bytes. In a post-covenant world I suppose this could change.

There is a risk of confiscation of coins which have pre-signed but unpublished transactions spending them to new outputs with large scriptPubKeys. Due to long-standing standardness rules, and the presence of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any such transactions exist.

In any case, if confiscation is a worry, as always we can exempt the current UTXO set from the rule -- if you are only spending outputs that existed prior to the new rule, your new UTXOs are allowed to be large.

I would even suggest going lower than 520 bytes.

A ScriptPubKey is the part of a transaction that locks a particular output. You can think of it as a set of conditions that must be met or instructions that must be followed in order to spend the output.