But exceptions are still just a glorified "oops, I failed".

So there are still a released software that suffered from an error detected in runtime instead of caught before shipping.

Some systems have huge control flow graphs that makes it almost impossible to create the stimuli to run all paths when testing. And with an interpreted language, there can be huge errors that are waiting to be found just because you can't manage 100% code coverage when testing before delivery.

In the end, exceptions (the computer language version with throw/catch) are good to return to a known state after more-or-less expected runtime problems.
And the hw version of exceptions (like invalid instructions, writes to read-only memory etc) are good to recover when something goes wrong with the actual hardware - maybe after a memory bit upset.

But for the quality of shipped code, we do want tools that can load and analyze the complete bulk of code and spot variables without volatile, critical sections implemented in ways where they may not unlock, use of uninitialized variables, ... Something that tries to find out if we have missed a dot on an i.