Also, in the 90s we talked about tests as another indication of programmer intent. Since we couldn't get developers to document their code and "design as a practice" fell out of favor, tests were the only thing left indicating how the code was intended to be used.
The linked article is a bit wordy, but I think what he's trying to say is: write tests exercising the behavior of interfaces because you may want to change your implementation some day. The drawback of this approach is we don't have a universal way to express Bertrand-Russell-esque contracts on interfaces, so testing behavior when you provide "unsupported" inputs is rather ad hoc.
My take is that one way to make sure that value > cost for tests is to use tests as a form of documentation or to support documentation.
One of the best applications for "literate programming" is to put all the code snippets in the documentation into unit tests. If you don't do that it seems impossible that you could write a book like The C Programming Language and have the examples really work.
The linked article is a bit wordy, but I think what he's trying to say is: write tests exercising the behavior of interfaces because you may want to change your implementation some day. The drawback of this approach is we don't have a universal way to express Bertrand-Russell-esque contracts on interfaces, so testing behavior when you provide "unsupported" inputs is rather ad hoc.