That's not the real problem with checked exceptions in Java.
You actually have the same problem with any result type in a language with static types and mandatory explicit types in function signatures - you change one type and you have to adjust the callers, sometimes many levels above. This is just life ;)
One of biggest troubles with checked exceptions is that in Java it is impossible to generify them the same way you can do with argument and return types. You can't write a generic filter or map function that throws the same checked exceptions as the lambda (or any other interface object) that gets passed as an argument. This makes it impossible to use code that throws checked exceptions in some contexts and forces developers to wrap them in RuntimeException.
And because those situations are extremely common these days, especially after some FP techniques influenced how Java code is being written, almost noone uses checked exceptions and you typically get runtime exceptions flying around the whole codebase. Which are even worse - they turn very quickly into an unmaintainable mess - because now any function can throw just anything at any time, and that's not even explicitly visible.
And here we get to the next big problem with exceptions (not just checked exceptions): they add a high number of alternative control flows you need to analyze in addition to the main "happy path" of the program. An exception can happen anywhere and it might leave the data in incorrect, partially updated state. In reality many devs simply pretend the problem doesn't exist, and they check the happy path only. In languages with no exceptions, a function can exit only by an explicit return - and that is way more readable and easier to analyze.
And the last thing which seems to be more a cultural problem, rather than a Java problem, is that somehow most Java programs communicate typical, expected problems with ugly and mostly useless exception stacktraces. Can't connect to a host? I get a stacktrace. File not found? Two screens of stacktraces... That's IMHO a terrible approach to error handling. As a user I am totally uninterested in what code was being executed when something failed (that should be reported only for bugs so the developers can fix). I'm interested in getting a human-readable message with context helping me understand what went wrong and how to fix it.