This is a nice sentiment, and the “CISC vs. RISC” debate is a great target for its own thread, but in general I think even when you set aside large script sizes and the difficulty of working with bitcoin script, CAT and CSFS are non-starters.
The amount preservation and batching features of the OP_VAULT design would require 64 bit arithmetic in script, as well as opcodes that facilitate taptweak checks (merkle operations), and pushing various parts of the transaction to the stack. The “deferred checks” aspect of VAULT, which enables batching (and would be required for signature aggregation), requires fundamental modifications to the validation code outside of script.
The “open sandbox in script” approach, again enviable for its permissionlessness, just doesn’t seem realistically workable to me given all these prerequisites. Or we’d be talking about a script overhaul that entails a much larger fork. There’s also probably a camp of people who would argue that it’d rather be worth focusing on Simplicity to get to that level of complexity in script.
And once we get there, if we got there, we’d have to contend with the brittle nature of writing these scripts and the ensuing on-chain footprint. And the eventual “jetting” of opcodes that emerge from the on-chain experimentation.
These criticisms apply to proposals like MATT and OP_TX.
I really see where you’re coming from on this one, and at a low level I agree with you, I just don’t think it’s the most expeditious path to making bitcoin much more useful on the scale of a few years.