Apart from the issues already mentioned by ABCbits, I'd add the following problems:

- a text/image detector can only identify codecs that already exist, and here we are again with the cat and mouse games ... the spammers are always faster.
- mandatory minimum fees: We have seen in the Ordinals wave that in the situation of such a "fad", spammers will be willing to pay very high fees (thousands of dollars in some cases, hundreds in many ...). The fees would thus have to be prohibitively high (higher than in the Ordinals wave fee top), so they practically would make Bitcoin unaffordable for all uses with exception of high value transactions.

By the way, @gmaxwell thanks for your explanation, while I think old P2PK outputs would then not be in danger, a lot of protocols would indeed.

You can use one definition of a softfork that is literally just "a strict tightening of the rules"-- and under that umbrella all sorts of things are "possible" like confiscating everyone's coins.

But that kind of free wheeling anything goes softfork is not something the network has ever accepted, and I expect would never accept.  What has been accepted is a much narrower kind of softfork,  but one we don't have a clear name or conscious definition of.

One element I think that backs every prior softfork and every one that ever will be successful is that it won't have a meaningful risk of confiscating anyone's coins, or at least anyone who wasn't doing something weird and stupid that could easily have been predicted to cause coin loss.  (Bitcoin isn't your mommy and if you want to fire bullets at your feet that's your own decision-- the networks obligation to save you from the reasonable and expected consequences of your bad choices is not significant.)

So, for example, most prior softforks (after Satoshi at least) have used explicit forward-compatibility mechanisms such as future tx-version numbers, segwit version numbers, or NOP-codes.   Now some maniac could have been using those do-nothing fields and caused themselves funds loss when they later got used as intended, but if they were it was an error and for no purpose except perhaps intentionally screwing things up.  For tapscript OP_SUCCESS makes it even harder for any prospective maniacs since any premature use of the forward compat renders the entire script insecure.

There are probably a dozen other such criteria that all existing softfork fits and that any successful one would need to meet... they're not part of a definition of "soft fork" and no one has written them all down or given a name to the class yet but that doesn't prevent them from being requirements and doesn't prevent them from making "but softforks could do almost anything" a useless argument as a prediction about what the network might actually do in the future.

Failing to acknowledge that is kind of like saying bitcoin could be expected to hardfork lots because a hardfork is a rule change, and given that Bitcoin has adopted many softforks (which are also rule changes) it can be expected to make other rule changes like hardforks.  It's a false equivalence that comes from being overly general.

There is the website short URL to the Bitcoin Improvement Proposal BIP-444: "https://bip444.github.io".