Not the OP, but I can answer your questions :)

Posting data in fake keys or hashes cannot be fixed without major changes to the protocol. You would have to disallow any sort of hash output (no more p2pkh, p2wpkh, p2sh, p2wsh - which are all still used!) and enforce that public keys in bare pubkey outputs (p2tr, p2pk) are actually valid. However you can very easily grind public keys to still mostly contain the data you desire, or tweak them by adding something to them, so this doesn't really help either.

As for utreexo, there is work being done in Bitcoin Core to make it easier for utreexo nodes to re-use the Bitcoin Core code for their own implementations. There is a chance that Bitcoin Core will eventually adapt their validation model too. I do think their model is attractive, especially for running nodes on devices with restricted io capability.

No, it does stop working for all intents and purposes. At the timeout will start rejecting blocks, effectively forking the node off the chain. If timed correctly, the node could be fed a chain with less work. This is arguably worse than just shutting down, since other services relying on the node will not notice immediately.

Edit to the above:

Should add a caveat to the first paragraph that this also depends on the network topology. If the peer just receives a header, and not a full "high bandwidth" compact block announcement, it is unable to reconstruct the block, and the block relay delay effect as described in the OP takes over.

Sure, here it is: https://github.com/bitcoinknots/bitcoin/blob/28.x-knots/src/validation.cpp#L4458-L4469

I should add that this is optional, but default on.

Thanks for posting all of this.

This is not necessarily true. While it can hurt propagation of compact block transactions to nodes that don't have them yet, the block announcement may be passed on immediately if the block header is valid. See this passage in the compact block BIP: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#pre-validation-relay-and-consistency-considerations . If the miner/block template producer already has all the transactions, because they run a lax standardness policy, they can then immediately reconstruct the block and validate it without any further roundtrips. Meaning this actually acts in the inverse; it puts a bit of pressure on miners to run a lax transaction policy.

As you point out in your second line of arguments, the above effect may indeed hurt miners that have more restrictive policies, since they spend more time reconciling compact blocks. But is the conclusion then that everybody has to run the most restrictive policy possible to not hurt those miner's bottom line?

One thing I would like to add to the explanations given so far is that I feel like Bitcoin Core is really caught in a hard place here. I think it is pretty clear that long-standing policy rules are effective, hence why e.g. counterparty back in the day did not build their protocol on it, and other meta protocols like Omni [1] were impeded by it, and eventually moved to other data embedding methods, like paying to fake key outputs. Most devs on the project, me included, are no fans of embedding data in the chain on a mass scale, or running parasitic, inefficient meta protocols over it.

I think the actual problem is really that a few years ago when the segwit discount was introduced, and again with the relaxing of the witness size in taproot, no policy adjustments on size were made. However, inversely to the dynamic of a soft fork and a hard fork, where tightening rules is done in a backwards compatible fashion, tightening and loosening policy have different dynamics. Tightening only becomes effective when an overwhelming majority of nodes run the new policy. Loosening becomes effective with even just a small proportion of nodes running it, as became apparent during the recent adoption of full RBF. To my knowledge policy has never been tightened on something in Bitcoin Core while it was in use. While this has many reasons that are explained elsewhere, I find the potential higher order effects of this on miner incentives scary. Making people upgrade faster by hard-forking older clients off the chain, like knots does, is a dangerous path to tread on for the entire project.

The hype around ordinals inscriptions has lasted for around two years (the mempool has cleared again, so I think it is pretty much done now); counterparty and omni had similar hype-cycles back in the day. I'm sure they will re-surge every now and again, but on the grand scheme of things, I think it won't be significant. If the fee market seems to historically starve these meta protocols after two years, and it takes about two years until more restrictive policy is rolled out in a comprehensive fashion, is there really much to argue about here?

[1] https://www.blockchainresearchlab.org/wp-content/uploads/2020/03/BRL-Working-Paper-No-7-Dominating-OP-Returns.pdf

@Murch has provided an excellent answer, but I would also like to mention that there were also some technical arguments in favour of retaining the option. It could allow an ideological miner with a stratumv2 or datum template provider, or ideological mining pool to exclude these OP_RETURN transactions from their block template. This has sparked a conversation around potentially separating transaction relay and mining policy, or even retaining the option for this reason. Some might argue even further that nodes adopting a stricter OP_RETURN size limit in their policy could be more likely to relay lower fee transactions to these miners or pools. However, I don't think this is a good idea for all the reasons Murch has laid out. The issue was opened here: https://github.com/bitcoin/bitcoin/issues/32401.

A similar option also exists for denying the usage of bare multisig (p2ms) outputs (-permitbaremultisig). These are a type of output intended for multisig, but widely used for data embedding through the counterparty protocol and stamps. It is currently default off. Making it default on, or removing it, have led to similar controversies in the past. My expectation is this will be revisited again too depending on the outcome of the current controversy.

The biggest shift came after it was hacked. Once it came back online most people already moved elsewhere. Many (including me) also had trouble getting their account back.

For what it's worth the issue of removing the option was raised pretty much immediately during review of the pull request by other Bitcoin Core contributors. It was then also discussed in a separate issue and on the mailing list. Seems like the current momentum is towards changing the default, but keeping the option.

I really like the following gmaxwell quote from 2015: "Since Bitcoin is an electronic cash, it isn’t a generic database; the demand for cheap highly-replicated perpetual storage is unbounded, and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage, and there is no shame in that." https://gnusha.org/pi/bitcoindev/CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com/

Clearly this is a political issue, it's in the name "policy" itself. I don't think attempting to minimize harm is caving to shitcoins. I think they should be held accountable socially, but we also have to face the fact that them anchoring data in the chain is inevitable.

They don't care if they store it in an OP_RETURN, or an unprunable output for which also no amount extra policy can stop them. They will post it either way. Giving them and others the option of doing so in an OP_RETURN, we at least give them the option to post their data in a way that is prunable.

Indeed, but the reality is that sadly people are doing it.

There could, but there isn't. I for one care about cash on the internet.