In the context of a (to me, rather silly) debate over improving Perl 5's object orientation tutorial, I staked out my opinion a year ago. The Modern Perl book assumes no knowledge of object orientation and introduces OO Perl 5 with Moose, favoring encapsulation, genericity, polymorphism, and roles and delegation and composition over inheritance. The subsequent chapter demonstrates the default Perl 5 mechanism of blessed references and explains that "You may have to maintain legacy code or write new code where CPAN is not an option, so here are the gory details."
In other words, I saw no good reason to expose novices to the core mechanism of object orientation.
With that said, you don't have to use Moose to write great Perl 5. You can write great Perl 5 with the default object system, though you'll have to write far too much code yourself and need great care and discipline to do so well.
To me, given the existence of one very, very good object system—and I double up the superlatives because it's so complete, from its theoretical underpinnings to its effective and almost seamless syncretism as well as working reflection which is horribly ugly where it's not straight up impossible with the default Perl 5 object system—and a handful of other good object systems on the CPAN, it would be irresponsible and even unethical of me to explain something else when the only reason to use the default object system is when you have to maintain legacy code.
Modern Perl is not about training a new generation of monkeys who can only maintain increasingly irrelevant legacy code. We can set our sights a fair bit higher.
Perhaps someday the Perl 5 core will have a better default object system (goodness knows it's difficult enough even to propose syntax extensions on which to build a better object system), but I sleep much better at night knowing that people who study the Modern Perl Moose chapter can write good code without tripping themselves up on the visibility and scoping of @ISA or worry about the differences between base and parent or paint themselves into a corner with single-argument bless or make refactoring difficult by eschewing encapsulation for direct attribute access or even writing lots and lots and lots of repetative boilerplate code, because I showed them a better option first.
They still have options if they need them, but at least they don't have to make ten years of mistakes on their own.
In 2003, I published a Perl 5 “translation” of the first chapter of the book “Refactoring - Improving the Design of Existing Code”, Addison Wesley, by Martin Fowler et al., on my website.
At the time, doing OOP in Perl 5 was not easy: you had several options, none of which were optimal. You could write everything by hand (lots of boilerplate), you could use Class::Struct, or you could use the fields pragma. Inside-out objects didn't yet exist, I think. I chose the fields pragma, for reasons I don't quite remember.
Rewriting the ugly old beast was long overdue:
Refactoring Example, Perl 5 version
It's now written with Moose, and I'm much more happy with this version. There are some issues that could still be improved, however. The step were the State Pattern is introduced, for example, surely has a better solution. I thought about applying a role to an instance at runtime, but what I don't like about that solution is that you can only add roles, but not replace them, so you add one level of indirection each time.
Perhaps someone has a better solution?