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