Perl, while it requires more discipline to make OO work well, really is a breath of fresh air, since it is unencumbered. However, you really do have to watch yourself carefully. Perl6 will fix much, and I am looking forward to it. But I have been long polluted by the evils of Lisp, a language where it is hard to get many things done, but once tasting the waters, you start to code Lispy things in other languages.

Yes, if you are new to OO, I don't recommend learning Perl OO first...but once you know it, Perl is definitely workable there (and the mixture of OO and functional concepts, to me at least, is the holy grail). Maybe you could learn it first, but be careful, and be sure to pick up a few others along the way to balance yourself as you dive into the depths of Perl modules.

One of the more seductive things about OO, especially in other languages, is the tendancy to overdue objects and limit the usage of constructs found in the core language. Java is the extreme for this, and in some cases it works, but in Perl, you have the feeling you can use as little or as much OO as you want. Also, being Perl can be a little heretical to the buzzword-compliance trends in OO these days, you feel less restrained and you have more fun. Perl culture, for instance, doesn't require overabundance of getter and setter methods as Java seems to -- which is good, because that is a misleading practice to begin with.

Anyhow, OO is loosely defined and is largely what you make of it. It's always subject to debate. To use pure objects? To mix paradigms? Where to go? Learn from others -- both from what they get right, and what they get wrong. There really isn't a true path to OO design, find what works, and don't stop evolving as a developer. I once was a huge hardcore "OO only" guy coming out of college. Industry has taught me a lot about balance and when to say no to excessive object proliferation -- but everybody looks on OO design differently.