What other ways might they use?
Inscriptions in their current form can be filtered by matching against non-executed conditional script branch opcodes, that is OP_FALSE OP_IF. This is what Knots does in CScript::DatacarrierBytes https://github.com/bitcoinknots/bitcoin/blob/271fd206893a164b2d1c2d1c44c3696d23dd10e9/src/script/script.cpp#L329C36-L381
Core proponents state that this is not good enough since, were this logic to be applied everywhere, inscription spammers would find another way to push their data.
Discussion
Probably endless when it comes to embedding data within script opcodes, I can imagine inscription spammers could easily update their protocol such that instead of embedding data within the OP_FALSE OP_IF .. OP_ENDIF envelope, they would do so within something a bit more convoluted, but still not executed as a logical branch, maybe take advantage of OP_ADD / OP_LESSTHAN etc etc
I think the only way to really remove the spam threat is probably by allowing only well known transaction types, which means a set of transactions even more restricted than what are currently deemed standard. I am not sure this approach would be definitive anyways, but it would be incredibly controversial probably and it would come with its own set of risks, if feasible at all. I am personally in no position to currently propose alternative approaches, even in theory, as I am far from being a Bitcoin expert, so these are just some thoughts off the top of my head.
It still helps. Thanks for giving your thoughts.