If someone tries to publish an old channel state the chances are he'll loose all his sats.
If my justice transaction is stuck in the pool because of a sudden peak in spam (and it has), all it takes is a CPFP to get it through.
Lightning has been working like this for years without any major issues...
My guess is you're using extreme cases with very low probabilites to justify the narrative for an unnecessary change to the current consensus (which sadly makes you sound like the "dickbutt" here)
You're assuming the operator is paying attention, which is a stretch. I'm not aware of any automated CPFP for that case.
It is an edge case, but the point is to illustrate a reason why one would, in fact, want things they don't like in their mempool. The same could happen with any transaction you want to make, resulting in a worse user experience when transactions don't get confirmed.
Ln node operators do pay attention: They follow their earnings, adjust the channel fees, rebalance the channels when needed, check for new incoming channels and closing ones. It's not a trivial job, and improvements can be made but that is a Ln issue, not a bitcoin one.
When the "inscriptions gang of morons" were spamming the mempool with thousands of junk transactions, there was no way to adequately determine the correct fees, and txs could stay stuck for days even when they were set to mine in the next 2-3 blocks. Spamming "monkey jpgs" to everyone won't solve the problem. What we need are smarter algorithms to estimate correct fees and I believe that can be achieved even without loading all the junk into everyone's pool.
I personally believe the trade-off is not worth it, and if removing the OP_RETURN limit is not set as an opt-in option, then I will either have to patch core myself or switch to #knots. Neither of which I'm looking forward to do.
