Look at transaction outputs instead. And notice that we still miss OP_CAT to make it complete. We miss it, because it can be used to do quines, and other naughty stuff, for the same reason OP_SUBSTR is disabled, also for example OP_AND, which can be used to emulate OP_CAT. Because it is possible to push some prefix, some postfix, ask OP_CAT to play with this wool, and then demand equality by using OP_HASH256 and OP_EQUAL. In general, "OP_HASH256 <someHash> OP_EQUAL" can be used for block header (always 80 bytes), merkle proof (always 64 bytes), or for a transaction (any size). Using OP_SIZE is the only practical way to distinguish it, because checking more things require more complicated script, and that costs more precious satoshis.

There are not that many things you can do with that. I can imagine the whole merkle tree, filled with low transaction hashes. And what's next? Then you can for example split the coinbase between them, based on the number of zeroes they contain. Or you can provide someone a transaction hash, and allow some tricks by exploiting length extension attack, if you need that for OP_CODESEPARATOR scripts. Then, someone can agree to sign something, without knowing the whole script, because it is about using OP_CODESEPARATOR to prepend some unknown script into that: https://bitcointalk.org/index.php?topic=5375893.0