The biggest problem I see with this article is the author is comparing Simula style OOP (Prevalent in C++, Java, C#, etc.) with procedural style programming and

The biggest problem I see with this article is the author is comparing Simula style OOP (Prevalent in C++, Java, C#, etc.) with procedural style programming and concludes anthropomorphism is at fault. When your objects act more like very lightweight processes ala Smalltalk or Erlang model that communicate with each other via messaging, OOP becomes a lot more than a "coat of syntax sugar over the procedural cake" and anthropomorphism sudden works very well. If you see objects as data structures with methods rather than isolated processes with message based interfaces (think actor model), it's not all that surprising anthropomorphisms don't add much value. However, when your conceptual model of objects implies each object is a concurrent and isolated process, anthropomorphisms make sense. I sometimes even give them names and imagine them as employees in an organization. Asynchronous communications can be conceptualized as inboxes and outboxes of messages and synchronous communications can be thought of one employee getting into a queue himself to personally deliver the message. Sometimes metaphors translate surprisingly when you become a stickler for making sure all aspects of a metaphor are accounted.