I forgot to mention scripts like InspectInputValue and InspectOutputValue are probably required too
That's why people are supporting OP_CAT: to not think about all corner cases, and to not activate a new soft-fork, and find out, that "hey, we forgot that one little thing, and we are stuck with what we already have".
it should be up to the protocol developer to determine what curve (and protocol math) they are using
Why do you want to support every possible curve, instead of simply using DLEQ, and having secp256k1 on Bitcoin, and any other curve you want, in some other place, like LN? Do you also want to support weak curves like "p=79, n=67, base=(1,18)"? Because the consequence of having EC_MUL, is to also have weak and unsafe curves, picked by the users. And we don't want to go back to those times again:
https://words.filippo.io/dispatches/parameters/That may also be used for migrating to different curves without hardforks.
You can do even more than that in the current system. You can actually deploy
Lamport Signatures, without any changes at all, not only without hard-forks, but also without soft-forks as well.
Current scaling proposals AFAIK have not considered how to tackle costing for every script that can possibly be written for their templates
The main idea is that you should spend coins by key. Then, a single signature is all you need. All features like OP_CAT, the whole TapScript support, all of those MAST-based branching, is only for disagreements (and for hidden commitments, which will be never pushed on-chain). Which means, that you should use a single signature on a daily basis, and a TapScript only, when another party stops cooperating, so you can say: "You don't want to cooperate? Well, then I am going to use OP_CAT, pay more fees, and enforce this contract on-chain!".