Thats where your assumption may be wrong. Anything that promotes going directly to miners, vs being relayable via nodes, is ultimately bad for node operators, decentralization, and layer 2
Discussion
I'm not worried about going direct to mining pools. I think it's about the utxo set and not even the size but probably the added processing needed to do the IDB and full validation. I was trying to think of the absolute worst case scenario were every single sat is used in its own utxo and inscribed with the max 4mb of garage data. How big would that make the utxo, how long would it take to get there and how long would it take to do a full validation. Then try that scenario with what might actually be possible in reality. Like how bad could it actually get. I didn't really think it through. Full nodes need to be able to do full validation and not rely on shortcuts. So writing all that out it does seem like unlocking op return is good as it would require less processing during full validation. And then if you still see transactions using inscriptions or whatever then you can reason that it's adisguised attack on Bitcoin.
Worst case scenario can be between the extremes of..
Every block is full, equals about 200 GB of data per year. A 2 TB drive will be full within the next 3 or 4 years and then time to upgrade to a 4 or 8TB
Or
No inscriptions, or even op returns... maximum number of utxos.. still between 1mb and 4mb per block, but increasing thousands of utxos per block.. with valid financial dust transaction outputs.
Point is that the utxo problem can occur no matter what, and needs separate disincentive. Eg. No hourly dca as utxos, keep it custodial in lightning or exchange and withdraw as lightning or larger utxo. Educate on common sense utxo sizes or 1,000,000 sets or higher. Samourai support for 100,000 is just as much of an attack as sphinx 100,000 sat channels. Main chain needs to be done with care. Every TX should be 3+ inputs, 2+ outputs