The security concern caused by EIP-1283 was contract reentry. Contract reentry, as far as I understand it, can only be caused by reducing the gas cost of storage opcodes (i.e., it cannot be caused by reducing the gas cost of computational opcodes). Only storage opcodes are relevant because the security risk of reentry is contract state change, which is only possible through an SSTORE (or maybe another state-changing opcode, e.g. a balance transfer with a CALL. Let’s call “state-changing opcodes” the set of all CALL* opcodes and storage opcodes; everything else is a computational opcode).
I agree that a thorough backward compatibility assessment is needed, but I’d bet that reducing the cost of computational opcodes is safe with respect to contract reentry.
The increase in cost of CALL from 40 to 700 also specified the “1/64 gas rule” to avoid breaking lots of contracts. Also, as I mentioned above, the cost of SSTORE has never been changed before (SSTORE and SLOAD are the two main opcodes whose cost need to be drastically rebalanced). Anyway, are you suggesting that cost increases can go ahead without versioning, and without thorough backward-compatibility assessments? Or should EIP-1884 (EIP 1884: Repricing for trie-size-dependent opcodes) also have a thorough assessment, or only apply to the new EVM version?
Btw, the problems with a cost increase of SSTORE are not mere inconvenience for tools. I mentioned this above, with links to previous discussion (see the paragraph starting, “Another discussion was in this thread: On raising block gas limit (and State Rent)”).