I'm generally pro-exception for truly exceptional situations, but I probably have a higher bar than most in deciding what's "exceptional".
What makes this hard is that the low-level code must decide what's exceptional, but only the high-level code knows whether a given error is exceptional. For example, consider a function that loads an icon. What should it do when it fails? Only the calling code knows whether the failure is critical (the program NEEDS that icon to proceed) or not (the icon is just decorative).
Practical issues tend to trump elegance. Constructors that fail have to throw exceptions in order for RAII to work. On the other hand, destructors shouldn't throw exceptions. Then there are all the barriers across which you cannot let an exception fly. For example, in Windows, it's not safe to let an exception propagate out of an OS callback (like a window procedure). If you're multi-threaded, an unhandled exception in one of your worker threads will bring down the process, without unwinding and calling the d'tors on your other threads. Device drivers and kernel code generally cannot use C++-style exceptions because of paging constraints. COM doesn't play nice with exceptions.
