I can see now where the resistance to "throwing away" the tests on private methods comes from, and I think it's because you are speaking of a fundamentally different approach to testing than what I've personally been exposed to.
With regard to unit testing, I've always though that you must test every non-trivial unit of code to ensure that it does what you expect it to do. This is why I (and I believe others) feel that testing private and protected methods is a worthwhile exercise.
What you're describing is a bit different than that, but I still believe you are correct. What you're saying (and please correct me if I'm wrong) is that tests should exercise the public interface of a class so that further down the line, any given implementation can be tested using the tests written for the original implementation. If the new implementation passes those tests, then it is a viable alternative implementation to the existing code.
With that being the case, testing the private methods of a particular implementation and requiring those same tests to pass on subsequent implementations greatly reduces the flexibility of the code, making it harder to refactor and update. This gets to the heart of the matter and would explain why you (and the writer you quoted) said to mark such tests as "delete this test if it fails".
I can see this as a much better approach to testing because it allows for more flexible code and easier refactoring, which is one of the reasons tests exist in the first place. Additionally, it makes you think about the code more, instead of blindly following the 100% Code Coverage mantra.
Lots of thinking to do now. Thanks for bringing this up. :)