Using the code example in this article as an argument on when and where or even the validity of using OOP principles and code is like using a flower to compare and examine the properties of a human. They both are organic creatures, to be sure, but there the simularity ends. Thier concept and deterministic purpose is simply at odds with each other. So too are the comparison of coding methodologies behind script oriented code and object oriented code. They not only come from different worlds and have differnt histories, thier intent for solving problems are completely different. Scripting languages like classic asp, sql, pearl and others are simply relative language scripts that at some point have to be interpreted and transformed back into objects in c++ or some other object oriented languages anyway. Object oriented languages were born to help programmers who were originally programming thier code in assembly to have more tools and prevent them from performing repetitive and non-automated tasks. Scripting languages as well, were designed to perform a specific task, to allow simplistic access to functions and creation of an underlying oo framework in a simplistic manner. I have been presented with the argument that making a simple primitive script in code is more efficient than using objects, thus:

for(i = 0;isomeValue;i++)
object obj = collection[i]

is more efficient than

foreach(object obj in collection)

because the first uses a simple iteration script and the second uses an iterator object to index through the collection. This is true for a very simple application, because the first way you are minimizing the number of objects in memory i.e no iterator object. But what if you have a more complex model? What if instead of a simple collection iteration you had a hundren thousand word essay to parse? Using a simple primitive collection of objects would be very inefficient then. So mabey choosing a Flyweight pattern to share instances of characters instead of creating them over and over in memory seems to be the more effective and optimized way to do things.
To understand something you don't first refute it before you understand it, you understand it then form your opinions on your new understanding. It seems like many junior programmers like the author has not had the experience to understand why you use oop and when not to. More complicated problems simply take a better solution. I do understand that some programemrs who have found themseleves on the positive side of understanding something about code can be quite enigmatic and arrogant about thier knowledge, or maybe do not communicate thier knowledge in an effective manner, which puts off people who do not have this knowledge. Or maybe you are making a good point when you say that oop does not cover every situation, which I would agree with because no single soution is a global boilerplate in computer sciences. But what the author needs to understand is there is a reason that evolves around understanding and thought towards a problem, and part of the understanding revoleves around understanding all the tools availiable without prejudice. Too often I have heard junior developers say that they don't understand why you use oop principles, when this other way is simpler. That argumentative attitude puts you at odds with knowledge. It would be better to ask questions and compare notes with other developers, and educate yourself into a place where you can make a competant argument towards a solution based on knowledge, instead of bullishly refusing to investigate your facts first. Just a thought, but in my mind arrogance in programmers is like having your trash man tell you your garbage stinks. No matter how smart any of us are, there are thousands smarter. So why waste time? Thanks for reading.