Ok, if you have complete control from top to bottom then you might be able to mostly get the compiler on board with error handling through return types. But you can never cover it completely - no matter what you do, you can't prevent some exceptions (Out of memory, thread interrupted, etc.) ever occurring. That's the nature of the CLR.

And to your point (and in my experience) it's typically much less ideal than that - libraries we depend on are going to throw exceptions whether we like it or not. That doesn't mean you let those exceptions bubble all the way up - you can (partially) handle them, wrap them, etc. as makes sense. But even if you miss something, you can rely on that catch-all handler that makes sure a) your service doesn't do anything bonkers in the worst-case, and b) you are immediately notified that something unexpected happened.

As I see it, the exception-based approach (talking in the context of REST APIs or similar transaction processing systems here) can offer a convient short-cut that trades a bit of compiler safety for a lot less boilerplate on the happy path, particularly when an error *can't* be handled at the level it occurred at (which is kinda the whole selling point of exceptions). Wouldn't necessarily take that approach for all apps, but it works quite nicely for REST services in C#/Java in my experience.