[i]I think the database access (specifically SQLException) is also a poor example, as it's debatable whether it should have been a checked exception in the first place.[/i]

OK but its debateable whether any exception should be a checked exception. For instance, InputStream - a fully abstract class - insists than any method may throw an IOException which must be caught (its checked). Yet there are instances of InputStream that do not throw this exception - yet the programmer is still burdened with writing code to handle exceptions that will not be thrown. This is a fundamental problem with static typing and hard wired method signatures.

InputStream in = new StringBufferInputStream(buffer);

int c = -1;
try { c = in.read(); } catch(IOException ex) {} // won't really throw

Of course, you can't exactly know that in is going to reference something that won't throw.

My biggest complaint though is that checked exceptions leak concerns of implementation into the interface. This results in very brittle systems.