Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions.
So yeah, want your implementation to consult a database? Sorry, the interface you must implement doesn't declare any checked exceptions, so say hello to app-killing RuntimeException wrapped SQLExceptions :/
Checked exceptions probably would have been fine if there were only one kind of checked exception. Most methods would declare it and they'd all be compatible.
This would be similar to how Go functions always return the same error type, but without the boilerplate.
I ran into this when writing an ANTLR parser. I wanted to throw specialized exceptions based on what went wrong in the parse, but these couldn't be checked exceptions for the above reason. So I had to derive them from RuntimeException, and then I wrapped the call to the parser so that it caught just this kind of exception, and re-threw it as a non-RuntimeException so that it was checked throughout the rest of the code. I think this is an ANTLR-idiom, which I found to be an odd quirk - but one that's unavoidable because of how ANTLR and Java are designed.
So yeah, want your implementation to consult a database? Sorry, the interface you must implement doesn't declare any checked exceptions, so say hello to app-killing RuntimeException wrapped SQLExceptions :/