In fact that's the reason why OP_MUL and similar OPs were disabled/removed from the code.
Meh, Satoshi disabled all opcodes that allocated memory because there wasn't any control to prevent them from allocating too much. It was an urgent vulnerability. You could do dup mul dup mul dup mul dup mul dup mul... and run every node out of memory validating it. Like cat a multiply output is the sum of the size of the inputs.
There was no fast way to make the validation engine safe because all the script numbers were openssl bignumber objects at the time, and there was no clear specification on how those suckers worked. God knows what consensus and resource exhaustion bugs existed there.
The story today would be different, script numbers are now integers not some weird library object. A safe multiply would be trivial to add (and there is one I think from elements that has been copied into a bunch of forks of Bitcoin).
There are clear uses for arithmetic operations, particularly it lets you implement some alternative cryptographic schemes... like for example an anonymous accumulator output.
But there is less of a case for implementing them in the abstract since the 'generic' things that get implemented may be too inefficient or just not do exactly the right thing for the use to actually work. So it's important to have clear use cases just to validate that the construct is actually useful.
I think things should be easier to justify with taproot, because if your application only needs to use the fancy opcodes in an exceptional case, the fact that they may be expensive to use isn't a problem.
Consider this scheme: A cryptographic accumulator like Zerocoin lets parties put in coins and then take them out without any linkage between the transactions. But it requires 3KB proofs making it costly to use. A group of N people could come together and create an output which has a musig2 N-of-N threshold signature as the root, and the expensive accumulator thing as a hidden branch. So long as all N people are online they all just jointly sign to make changes to the accumulator, keeping all the accumulator proof stuff private and offline. But if one of the N parties goes offline for whatever reason, no ones funds are frozen-- they can use the accumulator to kick out the unresponsive party at a one time cost and continue on.
Particularly if the N parties tend to pay each other often, this scheme is really efficient since it can encapsulate all the N*(N-1) potential payments between parties simultaneously in a transaction that uses the resources of a single party payment.
There are ways to do these schemes without a cryptographic accumulator, but once N is over a threshold size an accumulator is probably the cheapest way to implement it... even if it requires a pretty expensive script. Of course it's more useful the cheaper that backup escape hatch is, so it's important that the right operations are implemented for it. The simple and stupid multiply would probably not result in a usefully efficient implementation.
I don't say this to advocate for any proposal (I don't even known if any exist right now) but to just point out that there are applications and not just trivial or dubious ones.
