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.