Nope. Nope nope. This is the same argument that early OO people used to justify the idea that you should use getter/setters everywhere rather than directly accessing your variables. You never know if the implementations of those ideas will change!!!!!11
That's programming. It is always possible that anything might need to change. That is how it is. This does not justify calcifying your code by adding extra unnecessary structure, because what that in fact does is make the program harder to change later (while requiring you to do more work up front). Also, as the author of the article notes, it requires one to keep more pieces of information clear in one's head in order to work with code of equivalent complexity, something that is almost always a big lose.
In a good language, if a dependency implementation changes, you know this because your program does not compile. (Well, of course because you are not a noob, you are linking things that are versioned in the first place, so this should not ever even be an issue unless you are actively upgrading outside code and are expecting it.) When your program does not compile, you want the compile error to be at the site that uses the dependency, because that tells you exactly where the thing is that you need to fix. Adding excess verbiage around it, and distancing the site that instantiates the dependency from the site that uses it, only causes more work.
If you are using a language/system that doesn't allow you to program this directly and clearly, then maybe that is the problem...