Nothing wrong with it. Like nothing wrong with having nl2br function. Some don't need private class members. Some don't need nl2br. The wrong is when people think whoever doesn't need exactly what they need is dumb.

True, but why bake it into the language if it's not enforced? Most OOP requires encapsulation which requires private members and the ability to enforce this privacy. It should not be up to the user to enforce it, as that will never happen.

What's wrong with it? It's a bug by design that allows a useless feature (access to private members ... why not make everything public then?) and allows the destruction of a key concept of OOP: encapsulation.

Which is perfectly fine if you don't need encapsulation.

It seems your question is "why is there a 'private' variable convention, for something that isn't enforced by the language?"

The shortest answer is that it changes how people read the program and treat symbols branded with the underscore.

Empirically this has not caused rampant abuses or even unintentional mistakes of abuse of otherwise internal members, and so I think without more evidence that it's causing a problem now that this design experiment -- ill advised or otherwise -- has been tried and seems quite successful. Hence, an appeal to philosophy is not at odds with the implementation. The simple rule is "don't do that," coupled with "and it should be obvious when you are." Just as you probably shouldn't break into another class via reflection to use its symbols, as seen in Java or .NET, or use .send in Ruby, but still can. Python opted -- mostly for reasons of implementation complexity reduction -- to just do nothing at all.

I think this viewpoint changes quite a bit in a language that is amenable to being statically analyzed, though.