I see transactions in the mempool with op returns that reference previous transactions with inscriptions. It may be a sliding scale when it comes to individual blocks but it is not a sliding scale when it comes to the blockchain on a whole, they can use these options in tandem to reference each other.
Discussion
BTW, I saw this and thought it was interesting.
nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4sppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0sfm3mt argues that just because you filter a transaction doesn't mean you don't keep it in memory cache. You only refuse to relay it. Curious what exactly a filter does and doesn't do.
If your argument is that you just don't want it in your mempool, then it might be a strawman argument, but if you explicitly say you want to add friction to those transactions, that's fair.
I almost think it's more accurate to say "I want to prioritise standard transactions over data" or "I want the data transactors to feel unwelcome on this network" than to say "I don't want data on my node." or "I want to prevent data getting into my blockchain."
I want to add friction to those transactions so that users who want to make them would prefer to do so on another platform other than my money.
I think core developers should prioritize optimizing bitcoin for electronic peer to peer cash over data storage.