And its entirely based on my experience.

The fact is that the vast majority of busy developers don't have or don't take the time to follow your wrapping strategy. Its much too time inefficient and the payoff isn't really there (practically nobody on the user side of the system sees the benefit).

(There is a whole other rant I'm holding back on the excessive "wrapping" of layers - ie JDBC is already an abstraction layer - don't hide it).

Which tells me that its a failed "solution". I myself have become annoyed during a time crunch at changing the implementation of a method only to have a new checked exception appear in the implementation. The need to suddenly change the method signatures of every method on the call stack of said method (or take time out and write a wrapper exception class) annoyed me to the point that I simply swallowed it. Sue me I was on a time crunch. I've done this more than once BTW.

More importantly, this is rampant in code I see elsewhere. Which tells me that we haven't really solved the problem. More importantly, were these exceptions not checked and the burden of changing all the method signatures not there, a catch clause would likely simply be put at a reasonably sensible default location (like at the event polling/web request handling bottleneck) and its resolution could be incrementally improved based on the kinds of errors found in testing.