that same 10s or 100s is true for error returns as well. what do you do with those?
convert it to internal types at the point you're exposed to them, then handle them in common ways. or re-throw as a general runtime exception if you don't have a way to handle it in your application. the difference with checked exceptions is that you have a correct, complete list of error scenarios that a library expects you to handle, and they provide a relatively easy way to defer handling.
there's no need for your `public static void main` to inherit all 100+ exception classes that your application is exposed to - that's just plain bad encapsulation.
---
granted, none of this touches on some of java's implementation issues, which essentially suffers from a lack of generics. e.g. you can't build an executor-framework without `raises Exception` or wrapping all errors in an internal wrapper, which loses compile-time safety. typed-exceptions-as-returns (i.e. typed result enums) keeps them within the normal type system, which does have some benefits for sure, but that ship has sailed. few languages are able to force exhaustive error handling at all, java's in a middle-ground with pros and cons.