Vorlath wanders further afield:

Now we get to the real culprit. Method invocation. Allowing methods to be invoked at any time on any object is our generation's goto. This is also related to coupling, but even if you use interfaces, the problem is the same. There are no boundaries. Any object anywhere can basically create any object it wishes and start calling methods on it. I don't know about you, but most code I've seen consists of initialisation, method calls and control statements. Tracking all these method calls is what maintainers have to find out about. What do they do? Where are they? Is the source available? Can I change it if it fails? This has to be done everywhere. This is also where I see a lot of code duplication. One person does it one way. Then someone else comes along and finds an easier way to do things, but missed a few places where this same thing or something close to it is being done. Now your maintenance problem just went up exponentially. Maintainers usually know to try a compile by undefining some of the old methods, but this gets more difficult if there are other parts of your software that still need those calls or if your "easier way" uses those calls itself.

I'll agree with his assertion (not quoted above) that inheritance is overrated and over-used. However, the stuff above? How exactly do objects make this problem worse? The "initialize before use" issue does not disappear further down the food chain - I'd argue that it's easier to walk out into the weeds in C or assembly than it is in Smalltalk, for instance. I have no idea where he's going with this stuff, but so far, it's not making any sense at all.