In addition to wiser monks's words, i suggest you to read Damian Conway's ten rules for when to use OO.
Also, (consider that me i'm a self-made programmer, with no real experience in OO writing, only some aMooseMent..), it seems to me OO become useful in multi programmer env: the layer created by the OO design separates logic from interface (to the software). Programming is definetively an interface matter.

Consider another feeling: Perl is very democratic. When you approach a problem to resolve, you could be naturally inclined to describe it in a OO fashion: no problem: write down some Moose class, and run some instancieted voodoo against them.
Or by other hand you suddenly visualize a cached multilevel datastrcture returned by a closure and a jaggling way to manipulte it and to serialize it... go on on your way.

Another thing: when you'll need to maintain the code, what do you prefere? puzzling in possibly big a complex file or be mazed in a directory tree and in a meta-file hierarchies?

HtH
L*