Every piece of additional consensus logic has implementation and ongoing maintenance cost which is perpetual and can never be removed without potentially confiscating some user's assets.
When Satoshi disabled those opcodes he took a risk that doing so would destroy some user's funds, but Bitcoin was young, their usage was apparently non-existent, and those opcodes all could be used to cause effectively unbounded memory usage or memory corruption and crash nodes. I don't know
if Satoshi necessarily realised that he might be destroying people's funds, but given the threat at that point in Bitcoin's life (while Bitcoins
had very little value), it was probably the right call. It wouldn't be anymore.
Any newly introduced functionality isn't just a risk to the user, it's a potential risk to the entire network-- since flaws in it could result in consensus inconsistencies, node crashes, increases in worst case processing times, or even remote code execution vulnerabilities. Protecting against that requires review and testing resources which could otherwise be spent on other functionality. The costs are not one-time-costs either, since the code must be maintained and bugs could be introduced later.
Additional complexity also makes life harder for alternative node implementations, since they also have to implement every consensus rule, and it works against the users freedom to modify their own node (or implement their own). Because of these costs, "maybe someone will find it useful" isn't a really compelling argument.
The costs also mean that once some functionality is implemented there is reason to not implement something else which is partially redundant with it, so if flaws in a feature kill some uses but not all, it will be harder to get an improved alternative that covers all the uses deployed.
As far as the advantages of offering a simplified and mostly orthogonal instruction set, I don't think that itself matters much. While a proliferation of operations is a nuisance for anyone authoring an analysis tool, people can generally subset script however they like. Even if it would create a burden that users who need to jointly construct a policy have to agree on a common subset that their analysis tools are happy with, I think this cost could easily be offset by the added functionality.
If OP_BAR is a footgun and its redundant with OP_BAZ which is less of one-- just blacklist OP_BAR and only use OP_BAZ. But if OP_BAR is implemented first it may be difficult to make the case that that marginal improvement of OP_BAZ is worth its additional costs. So in that manner the implementation of a weak feature can get in the way of a stronger alternative that could have been done in the first place if an appropriate amount of effort had gone into it. The same statement is true if you replace 'footgun' with 'inefficient'.
Sometimes poorly designed features can have negative system incentive effects. For example, the original construction of time based nlocktime created an incentive for miners to lie about their current time, pushing it forward in order to be able to collect later nlocktime transactions and their fees. If time based nlocktime transactions became very common, this could have eventually created a race to the bottom where all miners were setting their times as far forward as they could to maximise their fees, and potentially endangering the stability of the network as a result even for users that don't use locktime. Fortunately nlocktime was fixable in a compatible way. Similarly, poorly constructed features could unnecessarily fragment the anonymity set or incentivise users to reduce privacy for everyone.
It's easy to imagine contrived features which would create negative systemic effects: E.g. OP_BOBSIG where a txout using it can be spent with no restrictions so long as Bob has signed the whole block -- an extremely efficient choice for those who trust Bob. And it seems harmless to people who don't use it, until you consider that it gives bob-trusters an unfair advantage, gives bob's mining an unfair advantage, and eventually might effectively hand control over the whole system to Bob. But systematic effects are a less common concern, since they require a feature that is attractive enough for people to choose to use it but unattractive for the system as a whole. It's still a factor that needs to be considered.
Other than in system effect corner cases most Bitcoin experts would agree that the owner of a funds should have complete freedom in how they choose to manage them-- even if that means they might sometimes choose an inefficient or less personally secure. Best practices can be addressed outside of the system itself. But because the consensus rules have to be implemented by all nodes and can't be removed, there are costs. These costs create situations where the the choice between a poorly and a well constructed operation-- or just between two totally different operations-- is to some degree mutually exclusive. Because of this a new feature not only needs to be safe for the network, it also ought to be clearly useful, and at least reasonably well designed-- otherwise it may use resources which could otherwise be used to deploy something more useful or better constructed.
