It's the old addage ... when you have a hammer in your hand, everything becomes a nail.
All too often programmers tend to do what they know how to do, even if there's a better way. It could have been anything from "I know how to build modules so ..." to "I will experiment with using classes ..." to some design or performance considerations that they didn't document so you don't know about them.
Rather than getting into the inner mysteries of OOP (which I'm only minimally qualified to do anyway) my approach, were I in your situation, would be:
* Look at the business problem. Is it bounded? That is, does the suite of functionality that you're trying to address have nice clean boundaries or is there a possibility that it could be expanded to do many more things than it does now? If you're dealing with a system that covers most ar all of the functionality that's possible then optimize for the current environment ... not for possible future additions.
* Can you identify "real world" entities that may correspond to objects (or classes) in the processing that's going on? One of my apps, just to give a concrete example, has distinct entities like "Users", "Stock Items", "Sales", "Sale Lines", "Taxes", etc. I can very economically refer to a "Sale" object (instance of the sale class) that contains a "User", a collection of "Sale Lines", collection of "Taxes", etc. It would be a truly nasty exercise to attempt to individually manage all those components manually but, because they are all encapsulated in the class, I don't need to. The class does it for me. If the business domain is more process driven (for example, read a record, do something with it, save it, print a report, etc.) Then you probably will derive less benefit from classes.
I'll give it some more thought and add to this post when I have time.