A lot of C++ developers outside of games don't use exceptions. It introduces a latent and hidden goto up the call chain in your code, and require additional bookkeeping by the program which slows things down. They're also dangerous when you update code because if you introduce a new exception in a function you need to update all of the call-sites. When doing this with monads or sum types, this refactor can be supported by the compiler as a function signature change.
It boggles my mind that Ada decided to include them. Unless you go through the entire call chain or use SPARK, you don't know for certain that one of the called subprograms won't throw. Even then, you could still get a `Storage_Error` or `Program_Error` for various reasons.
Unfortunely C++ suffers from having people that are so crazy about performance, yet never bother to learn how to use a profiler.
That is what boggles my mind, how one can be writing C++ as if they were fitting Assembly into 8 bit home computers, but never bother to learn how to use something like V-Tune.
By the way, there are other languages besides Ada with exceptions used for systems programming, and if they aren't as big as C++ it is only due to how market adoption has evolved, which had lots of factors not "does the language do exceptions".
I do work in software performance. The people I know who don't use exceptions work at HFT firms and in games, but in general, my point is that there's two reasons for not using exceptions:
1. performance
2. not wanting jumps or hidden control flow
Note that with exceptions you're forced to consider C++ exception guarantees for code, which can result in convoluting your code to ensure specific guarantees are met (like using swap to ensure that containers retain previous values), which often gets ignored or implemented incorrectly. Also, with exception specifications being deprecated, you have to rely on documentation or reading code to understand what exceptions might be inherent in other code.
It boggles my mind that Ada decided to include them. Unless you go through the entire call chain or use SPARK, you don't know for certain that one of the called subprograms won't throw. Even then, you could still get a `Storage_Error` or `Program_Error` for various reasons.