I strongly dislike class-making frameworks that everyone and their dog wants to bolt onto the side of Perl. So I'm not going to be writing any plug-ins for one. I've never seen any significant value in any of them and most of them look quite prone to break things due to ETOOMUCHMAGIC (and I've seen several actually break things), so I'm quite happy to avoid all of them completely. I don't find it particularly challenging to implement reasonable classes using just Perl 5 and I like that understanding my code doesn't require understanding some extra framework first.

I try to (and succeed at) avoiding inheritance in most cases, especially in Perl. Inheriting interfaces (aka pure-virtual classes) is a fine thing. Inheriting from a class that contains code is very often not the best solution and I (and many other experienced developers) know all too well how inheritance binds very tightly and can lead to brittle designs that become a burden.

So, if Perl had interfaces I might write Perl classes that inherit from more than one set of interfaces. Since Perl doesn't have (non-trivial) interfaces, I only rarely use inheritance in Perl and I have never been tempted to use multiple inheritance in Perl.

If I had new-fangled near-inheritance tools (traits, mix-ins, or whatever you want to call them), I'd probably make use of those more often.

I find that I'm more successful in the long run when I bend my approach to a problem to fit the language that I'm solving it in, rather than trying to bend the language to fit my first choice of approach. So I write Perl 5 classes in Perl 5 OO and easily resist the urge to try to turn Perl into my ideal OO framework, even though Perl often appears to make it somewhat easy for you to bend it.