Object Orientation should simply be seen as one tool in the toolbelt.

I think that it excels at a few things:

• Providing a simple interface to a subject with complex internals.
• Providing a degree of autonomy to entities.
• Making a new entity act or be acted upon in a way that seems already familiar (tied variables, overloaded operators, etc.).
• Giving data an inherent context (I'm not talking about context in the Perlish usage, but rather, context in the conceptual sense), and a standardized means of manipulation.
• Extensibility through inheritance.
• Multiple instances! (almost forgot that one)

Of course that's not a comprehensive list, and some of those notions can be addressed without OO. But OO can provide a convenient means to those ends.

For those reasons, I happen to like using CPAN and core modules that have an OO design better than ones that don't; they just seem to be easier to use once the OO notation is understood.

But OO design can also be overkill, and may add to confusion if not well thought-out. But the same can be said of many tools. Use a screwdriver for screws, and a hammer for nails. And if you need to chop wood, a chainsaw is handy. But don't try to drive nails with chainsaws; you'll get hurt. Use OO when it makes sense, when it simplifies design, when it is helpful. Bag it when some other approach is less of a headache.