No programming language will solve the problem of bad programmers. If you can edit the code, private methods provide no protection -- the programmer that wants to get at that functionality will just change it to public and recompile, or worse, cut-n-paste the code into his own module. The enforced privacy, therefore, adds no safety. Not enforcing privacy at least allows you to write a subclass that carefully changes the behavior of the original, at the risk of coupling the subclass to the superclass (but this is better than cut-n-pasting).
In an ideal world, you could rewrite every library that was designed incorrectly, but there is not always time for this. Intentionally limiting flexibility ("private") is worse for code reuse than allowing someone to intentionally change internal details. (Which is what privacy prevents.)
A good programmer will use his judgment to determine whether to cut-n-paste, subclass, or rewrite. The programming language should not remove options from his toolbox.
Now I work for a big tech company, and I'm in charge of a framework again except now its JavaScript which has the same problems when people force this classical inheritance pattern and now when some guy doesn't get it he's in another building or another country and did so in a repository I didn't even know existed and his code that breaks my encapsulation is in a production device and when I refactor my code I have the possibility that I break live code on some project or some device I don't know about.
Well, the tests stop passing. The tests are what ensure your code works, not "private" directives. "private" is just documentation that suggests "you probably don't want to call this directly". "Probably."
All I can say is that technical solutions to social problems never work. Rewrite your app in Haskell and I guarantee that dumbass developers will still be able to mess up your code. People are much more clever than programming languages.