As almost always, we programmers / software developers / engineers, forget to state our assumptions.

In closed-world, system-software, or low-level software you want to have your kind of knowledge about everything you call. Even more: can it block?

In open-world, business-software, or high-level software it is often impossible or impractical to know all the ways in which a function or method can fail. What you need then, is a broad classification of errors or exception in the following two dimensions: 1. transient or permanent, 2. domain or technical. Those four categories are most of the time enough to know whether to return a 4xx or 5xx error or to retry in a moment or to write something into a log where a human will find it. Here, unchecked exceptions are hugely beneficial. Coincidentally, that is the domain of most Java software.

Of course, these two groups of software systems are not distinct, there is a grey area in the middle.

Monadic error handling (such as Rust's) is a good compromise because it allows you to handle errors precisely when you want to _and_ bubble them up with minor boilerplate when you don't. You can even add context without unwrapping the whole thing.

That's why it's often considered one of the better approaches: it has both the "errors as values" benefits (encoding errors in the type system) and avoids many of its problems (verbosity when you just want to bubble up).