Whether or not exception flow control has a cost, it forces you to add code elsewhere that does have a cost which only exists to make the program exception safe

Whether or not exception flow control has a cost, it forces you to add code elsewhere that does have a cost which only exists to make the program exception safe. Some objects cannot be safely destroyed at arbitrary points during program execution because it will corrupt memory, leak resources, etc. In a lot of systems-y code you can have things in-flight that the code can’t reliably stop or undo as an intrinsic property of the system. If errors occur, you have to partially defer the unwinding of state indefinitely (or block) until it is safe to do so. This is pretty idiomatic for things like high-performance I/O. Making this exception safe requires much more defensive programming. You need extra code on the happy path to collect context in case of an exception, extra code in the error path to interpret that context to figure out what is and is not safe to destroy at the point in execution where the exception occurred, and extra code in the handling path to execute the deferral logic based on an interpretation of the context. With return code style handling, this is usually implicit in the structure of the code. It is much nicer to do this at compile-time than run-time. If you only write high-level C++ then this might not apply but most C++ tends to be used for systems-y software these days. The widespread practice of disabling exceptions for C++ code bases at companies big and small didn’t happen for no reason.