In that situation, you'll be the one blamed. It is unfair, but that is what will happen.
For a case in point, Microsoft encountered this one repeatedly in the 80s and 90s. (It didn't help that sometimes it probably was their fault..but most of the time it wasn't. It really, really wasn't.)
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.
I said advise your users and trust they won't do insane things. This allows your users to patch/hack in their application code, as a temporary or exploratory thing. I didn't suggest releasing libraries that themselves monkey-patch dependencies (ugh).
The OP is literally suggesting replacing "private" with either "public" or "protected" in C++ code, and then expecting comments/documentation to communicate what was already communicated previously by "private".
I'd argue that the post is too theoretical, in practice, enforced privacy works much better. People will do stuff against your advice. That's OK, you say - they'll get in trouble eventually, but it was their decision. However, it affects you, the library (app, etc.) developer, as your clients might turn out to be more powerful than you.
Think of Linus' rant on not breaking userspace. He's right I believe. In general, you are not allowed to break client code, even the client did something he was discouraged to do.
Interfaces are contracts. The ultimate documentation is the code, not the comment. You are saying that in the following case,
// do not access;
public int getSize();
comment has precedence over the visibility modifier. Well, no.
So in my eyes there are plenty of downsides for no visible upside - in all other languages the developers seem to play well and not write code to access privates. Maybe that's due to incompetence though.
The object's creator has made a machine. There are external controls and parts you need a screwdriver to get to. If you're using your screwdriver, you know it and should be OK with some risk. But the box isn't welded shut.
When I learned to drive, my tester required that I demonstrate competence with the controls, using them at the appropriate times, in the appropriate ways.
If my car exposed all of its private internal operations, I would have needed to know how to use them, and demonstrated that I know that. I haven't a clue about fuel flow and gear ratios, or air/fuel mixture or how the thermostat affects how the engine operates. I'm quite happy that I didn't have to demonstrate all of that too.
What the article ignores is that a good API provides everything the consumer needs, while keeping the API small and easily comprehensible. A driver who has to keep track of 5 details is more likely to learn to use his car more quickly, and less likely to crash than one who has to keep track of 200 details and make decisions about each one.
I often hear people nostalgically talking about how it was better in the olden days when people could fix/tweak their engines as they wished. If you lift the bonnet of my car it's a sheet of plastic and a few colour-coordinated filler lids so that I can top-up fluids. No hackability whatsoever.
Sure, an epoxy-encased engine isn't going to let me tinker with it, but I will never tinker with my engine. That's one of the wonderful things about separation of concerns that OO gives me, including all the perceived badness of enforced privacy: I can work on my particular thing without needing to know anything about the innards, because it is not my responsibility to do so, neither explicitly through delegation of concern and documentation, or implicitly through presentation of a semi-private API.
If I'm able to see it, then I'm expected to see it, and that blurs the lines of the API.
On your analogy, the car has a small number of controls visible and they're all you need 99% of the time. But the engine compartment isn't welded shut.
In FOSS libraries that I maintain, methods and properties that I don't want to expose are prefixed with an underscore and designated as protected. Protected members are not directly accessible, but anyone who wishes to play with them can create a subclass to access them. They also don't need to make any further changes other than subclassing, whereas private members might need to be overridden or (even worse) reimplemented depending on the language. So I think "protected" hits a nice balance between simplicity, openness, and maintainability.
The requirement to create a subclass to access protected members might come across as an inconvenience, but it sends the same message as the article's "dodgy" JS syntax: Here be dragons, tread carefully and don't blame me if your app breaks. It would be very nice if users understood that the leading underscore is meant to send the same message, but since they're apparently not getting the message, a little more inconvenience might be needed.
Then there is a matter of "well, it's not MY fault if you didn't use the public API and your code is now broken." I recall even Steve Jobs chastising developers for doing this.
Building something with a sensible yet strict privacy model takes a lot of upfront design. Makes sense for code that will be used by the masses, but maybe not for a small project.