Edit: Parent was edited, previously suggested "Java-style exception specifications". As far as I know every language with "throws clause"s has the kind of problems I describe below though.

Three major problems: they interact inconsistently with generics, you can no longer take a function's result and store it as a value, and you still can't tell whether a function might throw by looking at the point where it's called.

A good version of exception specifications would be lightweight syntax sugar over either (in the same way that a good version of async/await is a lightweight syntax sugar over futures/promises). But I'm not aware of any language implementing that; I guess once you have working Either there's not enough value in providing an alternative syntax for it.

Actually I thought a bit and realized that I don't want to defend checked exceptions. Let me amend the previous answer to "I prefer such functions to be interchangeable".

If those functions are interchangeable then you potentially have to deal with exception control flow on every line, or even within a single line. It makes it very hard to reason about all possible paths through a given function and do things like safe resource management (e.g. you always have to handle the possibility of further exceptions in your exception-handling code path).

For system failures it's ok because the only handling you're going to do is retry at high level (and so even languages with an Either-oriented style tend to have some form of "panics" or exceptions for that kind of failure). But it can be a real problem when that also happens for "normal failure" paths like bad user input where you want to actually have business logic that handles and perhaps recovers from the failure.

I think you can often avoid reasoning about all possible paths, by having one try-finally block per each resource to be freed.