What I mean is, when OP_IF or OP_ENDIF occur in a script without its counterpart, the whole thing (and all associated funds) ends up ruined and unredeemable.
I think this is an accident waiting to happen; are there any theoretical repercussions to simply ignoring an OP_IF without an associated OP_ENDIF and vice versa?
Theoretic repercussions? No, although I would personally have preferred to make such a script just syntactically invalid and illegal in transactions.
The point is moot though: changing this requires a hard fork, which brings huge risks that nobody is willing to take for trivial issues.
Softfork*
Too bad we can't make it non-IsStandard in P2SH, but by the point we know it's too late :(
What about rejecting such a transaction from the core wallet RPC interface? That would at least provide some warning about it
It's infeasible (with at least cryptographic hardness) to identify every unsatisfiable transaction; just catching a few classes is unlikely to save someone unless it was especially easy to hit (and if so perhaps should be fixed at the source). That it catches some but not all might give a false sense of security.
I think a more general script-lint would be interesting, but probably shouldn't be part of the rpc.
A linter could probably be created from libbitconsensus relatively easily if we added a mechanism for getting the error status. In this case, it'd be set to SCRIPT_ERR_UNBALANCED_CONDITIONAL.
I don't think its useful to keep this issue open any longer, its not really a bitcoin-core specific issue, maybe more suitable for a feature suggestion to another tool (e.g. https://github.com/kallewoof/btcdeb)
A linter should probably be another tool