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.