Thank you for tackling this difficult subject and doing so in a very well written manner. I'm going to take issue not with your article, but with the practices recommended in it.
Principle one says to use unchecked exceptions for programming errors. This I mainly agree with, although it should be noted that the very large and very public-facing website of the very large and very public-facing company I am currently consulting for was nearly levelled by RuntimeExceptions percolating up to the servlet engine layer. While, of course, this should have been caught in testing, that can be said of all bugs. There was a checked exception handler in place, but no unchecked exception handler because--not surprisingly--people tend to forget about RuntimeExceptions.
Principle two is almost spot on, except that I would never convert a checked exception into an unchecked one. By your article's own logic, the author of the checked exception determined that a client should be able to do something with it, so what would be the point of negating that decision by shoehorning the error into an unchecked exception?
Principle three I disagree with 100%. Often times a new exception class allows message generators the ability to perform instanceof checks to see what went wrong. For example, I've written a class that takes in an exception chain and uses user-supplied patterns (of sorts) to decide what message to return for that chain. The patterns make use of lots of class checking, which I find very useful. A chain that contains a FrobnicatorExplodedException (with no extra methods) that wraps a PrimingFuseActivatedPrematurelyException (with no extra methods) is easily parsed by the message generator if it can simply check for instanceof or isAssignableFrom().