Retweeting this, and also explaining the direct impact on @BtcPayServer. (But first, read Antoine’s post with a cool head, even if you dislike him.)

𝐓𝐋;𝐃𝐑: Most deployed BTCPay Servers will, sooner or later, be bricked. The change to the OP_RETURN size limit may prevent this. Here’s why.

When I created BTCPay Server, a hard requirement was keeping costs as low as possible and do not require our users to use command line. That’s why we love Bitcoin: everyone can verify.

The most popular option was (and still is) to buy a server on LunaNode. You could host BTCPay for $7 per month (M2 instance).
It comes with a 20GB SSD.

𝐇𝐨𝐰 𝐰𝐞 𝐤𝐞𝐩𝐭 𝐬𝐞𝐫𝐯𝐞𝐫 𝐜𝐨𝐬𝐭𝐬 𝐥𝐨𝐰

To keep costs down, blocks are stored on a separate volume of ~80GB. Our default deployment runs in pruned mode. This means blocks are downloaded, verified, stored temporarily, and discarded over time. As a result, the volume size is always sufficient.

Bitcoin doesn’t only store blocks; it also stores the current state (the UTXO set), which requires high throughput. Because of this, unlike the blocks, it isn’t stored on the separate volume but on the main drive (20GB).
The UTXO set size had always been relatively stable at the time, so 20GB was considered enough to keep costs low.

Up to 2022, the UTXO set was about 4GB. Now, it’s around 12GB, almost entirely due to spam. Uh oh.
This means very old BTCPay Servers on M2 instances will soon be bricked (since the 20GB must also hold the OS).

If you create a new server on LunaNode today, the default is now M4 (twice as expensive, $14 per month).
If your server is still running on M2, I strongly advise upgrading ASAP. Once the storage runs out, your server won’t be able to restart. Upgrading after that point may or may not go smoothly. Regardless of all of above, M4 is recommended as it also improves stability.

𝐓𝐡𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐨𝐟 𝐮𝐧𝐛𝐨𝐮𝐧𝐝𝐞𝐝 𝐬𝐭𝐨𝐫𝐚𝐠𝐞 𝐠𝐫𝐨𝐰𝐭𝐡

If the UTXO set keeps growing forever, it’s a big problem. You couldn’t just set up BTCPay Server and forget about it; you’d need to monitor storage and upgrade your machine periodically. That’s a high technical barrier for most merchants.

As Antoine points out, the specific spam has two approaches: one using unspendable outputs, and the other using OP_RETURN.

The nice thing about OP_RETURN is that it’s only stored in blocks, which means your node can safely discard it. Thanks to this, the UTXO set growth can stay stable, or even shrink.

𝐓𝐡𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐨𝐟 𝐟𝐚𝐬𝐭 𝐬𝐲𝐧𝐜

Another issue with a larger UTXO set is fast sync. Setting up a new BTCPay Server could once be accelerated by downloading 4GB of data instead of the entire blockchain.

Now it’s 12GB. As a result, we’ve reduced the frequency of fast sync snapshot updates for BTCPay Server.
This makes bootstrapping a server way slower.

I know all of this doesn't cover all your grievances on Core (why don't they just keep the knobs?).

I know that there exists way to make the problem of the UTXO Set size go away. (why don't they just implement Utreexo, X/Y/Z?)

But suffice to say that those solutions are far from ready, and wouldn't depend solely on Core to work in practice.