There are a couple of options, but none of them would be effective:

1) Hard-coded blocking of Ordinal-style Taproot scripts. That's what some (Luke-Jr et al.) have already "implemented" with a "patch", but it is absolutely uneffective, because the Ordinal guys simply could change the protocol in a way it's not detected by the patch. There should be lots of options to do that. So there would be a permanent "arms race" between the pro-Ordinals and anti-Ordinals fraction, the Bitcoin code would become complex, and less maintainable. Maybe the "Ordinals dynamic" could be slowed down a bit but not stopped if there is enough FOMO potential.

2) Limit the size of some Taproot scripts. That's what a small altcoin, Peercoin, did with a RFC implemented in version 0.12.3. I have favoured that method in some earlier posts when big NFTs were the main problem. But this would only stop big NFTs to be created (depending on the kB limit). And the current problem is caused by BRC-20 transactions, which are very small in size, and thus would not be blocked by such a patch. The problem is not the size of the BRC-20 transactions, the problem is their number. You can see in this graph that the small inscriptions, like BRC-20, are causing almost the whole congestion:



Source

There is also a general problem: Even if the developers managed in some way to block Ordinals completely, the BRC-20 crowd could simply swap their memecoins to another competing token standard like Counterparty or Omni. It would actually be a little bit better, because BRC-20 tokens are extremely ineffective regarding data usage, which was even admitted by Casey Rodarmor himself (who did not create BRC-20 nor does endorse that standard). But it would not solve the problem completely.

So what can be done? I think the approach has to go into another direction: support sidechains, LN and other off-chain and partly-offchain techniques like rollups.