Missing the point (OOP in scripting languages)

Yesterday I came across a question: Do Web-Scripting Languages Really Need OOP?
Here's my answer: only if you want to do more than an Hello World script (which is paradoxically how old school programmers measure the utility of a language.)
I'll express some of my thoughts without compromises, which will be up to you.

The author is equilibrated, as he saw the design simplifications that object-oriented programming introduces. However:

But our main point is that use of PHP constructs for OOP is a very “tradeoffy” and pragmatic decision, which we have often seen made more on the basis of religion or fashion. If you are comfy with OO, this kind of syntax is there for you; and if you work in a group that has decided to write in that style, you may want to let the majority rule. If you decide not to go OO, however, be strong—we urge you not to be swayed by the moral-superiority arguments you may hear from people who disdain your five-line procedural script in favor of their ten-line OO script that does exactly the same task.

This is not about 5 lines vs. 10 lines. If your projects are that long, go ahead. But hasn't the fact that every PHP framework is object-oriented told you something? The web is evolving from displaying documents to executing applications in the browser. The complexity will only increase in the future. When do you encounter 5-line script anymore?

What worries me are some of the comments:

However, in the PHP community there are very strong tendencies to cargo cult programming. Private methods and attributes make sense in Java, from where the idea was copied, but it adds little structural integrity in scripting languages (that's why Python eschewed them). But still, many PHP coders consider it "right OOP" to mark as many attributes as private as possible; neverminding that it only shadows underdesigned interfaces.

Private properties are available for encapsulation, not for structural integrity. I mark items as private so that I can change them in the future while only looking at the source code of their own class, and never worrying about external dependencies.

The likewise silly namespace\syntax also gets quite overused already. Deeply nested namespaces make sense in Java, but add little of the pleaded name conflict protection in PHP. It's just another syntax construct that gets used purposeless because it's hip. 

Namespaces are good because they remove duplication: you refer to the full class name (which can be quite long, such as Zend_Controller_Action_Helper or Zend_View_Helper_Url) only one time, at the top of your source file.

I'll give you one single reason to switch from procedural to object-oriented programming: seams.
In plain old structured programming, functions refer to other hardcoded functions, in a rigid graph. In OOP, object are (should be) wired at runtime, during their creation phase. It's this mechanism that makes practices like unit testing and polymorphism possible.