Shades of "boring technology"[0] which might better be described as "choose technology that is a good fit for the problem, proven, reliable and proportionate. Spend your innovation tokens sparingly and wisely".
- running on a VM (now boringly normal)
- using a pure-functional language with immutable terms (the pure-functional language fad has since then come and gone and this is now archaic and passé if anything)
But languages only get stereotyped once. At any rate, it's pretty boring and old.
Say your code divides by 0; the runtime system can't handle 1/0 but you the programmer may have anticipated this and know what to do. This is just someplace you write code right there to handle the case (catch an exception, pattern match the 0 case beforehand, whatever).
Your error, on the other hand, means something you expected to hold didn't; recovery inline from unknown unknowns is a fool's errand. Instead you give up and die, and the problem is now the exception you know how to handle "my child process died".
In brief, a checked exception is part of a method signature, "function wash throws NoSoapException", and the compiler enforces that whoever writes code calling that signature must make some kind of overt decision about what they want to do when that exception comes up. That may mean recovery, wrapping it inside another exception more-suitable to their own module's level of abstraction, deliberately ignore/log it, or just throw a non-checked exception.
So in a sense checked exceptions suit those "error" cases where you do expect the programmer consuming your function to at least decide whether they can handle it, and if they don't you still get all those wonderful features like stack traces and caused-by chaining. In contrast, regular (unchecked) exceptions have the opposite expectation, that the caller probably won't be able to handle them anyway and must opt-in to capture them.