We need the performance, and are frequently at least testing if not running in production on bleeding edge hardware, which almost always supports c/c++ first. That doesn’t make it for everyone though, and honestly I normally tell people to avoid exceptions as much as possible. The big issue is that C++ as a language was designed with exceptions in mind. There is no other way to exit with failure from any constructor that the caller can deal with, so every non-exception class has to use a two-step setup to avoid throwing in the constructor. If you’re doing exception free for real, meaning you can still recover rather than turning them off and just letting the program abort whenever a throw would have occurred, it’s actually a much harder language to write for.
Don’t get me wrong, maintaining exception guarantees and ensuring exceptions are appropriately caught is terrible. I much prefer working with optional and outcome and similar personally, but the assumption of exceptions is very deeply baked in, and avoiding them safely is a lot harder than one might guess.
Also, remember that while exceptions cost code size, they cost literally nothing in instructions executed unless an exception is actually thrown. That’s why the common nix implementation is called “zero cost exceptions”. In the happy path case they are faster than returning a discriminant. It’s not having exceptions available that makes code slow, it’s using them for things that are expected rather than unexpected or for control flow.
