Actually it can be quite a useful function. In your __unsubstantiated__ opinion it's dumb.
EDIT: You want to talk about dumb. An incomplete object model that has no concept of protected members and doesn't enforce encapsulation on "private" ones. This is worse than PHP4 and pales in comparison with PHP5's object model.
What's wrong with not enforcing privacy? I have not seen privacy be abused writ large in Python programs, except in cases that are very practical (mostly finicky forms of testing that hit a few critical code paths).
I have fairly recently written code in both Python and Ruby, and of the many qualitative differences in how these cultures and languages influence projects written in them, it has never occurred to me that 'real' privacy in Ruby vs. convention-based privacy in Python was the cause of any noticeable difference.
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.
EDIT: You want to talk about dumb. An incomplete object model that has no concept of protected members and doesn't enforce encapsulation on "private" ones. This is worse than PHP4 and pales in comparison with PHP5's object model.