I'm in nearly complete disagreement with the author here. I guess it helps that I've been burned more than once when using code from two third parties where party A reached into the "private areas" of party B's code. Rather than working with party B to resolve the incompleteness of the solution, they work around it and then push it to everyone. Later, when party B makes a change ("Hey, it's private, and the public interface doesn't change!") and suddenly breaks A's code - there are a bunch of un-related other parties which now have a nightmare on their hands.

Case in-point (of which there are many, I'm sure): QExtSerialPort. The author needed access to underlying Windows functionality that Qt didn't publicly provide, however, there was this nice, private header file laying around they could use. The Qt team later decided they wanted to remove the contents of that file, because no one should ever be using it. Anyone who wanted to build QExtSerialport had to go and grab the original file, and put it into the correct location. If they had instead submitted a patch to Qt to fix the problem, many hours would have been saved.

The author might get more points with me if they added "keep private usage private," but instead they are advocating accessing private internals of 3rd party tools in new open-source projects, which restricts the original developer from making changes without impacting users of the third party tools. Privacy is important - if you want to go around it fine, but you have to expect the price for you and your users, to hand-wave around that is naive at best.