There has been previous discussion of Moose being anti-modular (the Anonymous monk has given links to some of those), and those arguments apply to Moo as well, even more so.
The concern here is that using Moo leads to code which is un-modular. A simple example showing how easy it is to go off the modular path is in this subthread, which was looking at how to implement a bounded queue.
Logically, the operations such a queue should support are "new" (construction), "push" (adding an item) and "pop" (removing an item). In a hand crafted solution this is exactly what you get. But in a Moo solution you also get an operation called "items" that returns the underlying array ref. This defeats encapsulation, so is un-modular (it would be like putting a button on an ATM that allowed regular users to dump out all the cash). An example showing this version of the queue is not bounded after all.
An interface with, say 20 methods is harder to change/support than one with 5 methods, yet with Moo you typically end up with fat leaky interfaces, because all the attributes are part of the interface. With Moose you can avoid this by declaring an attribute as "bare", but Moo doesn't support this so the nearest approximation is to use a convention like
$obj->_get_foo() (but neither of these practices seem common judging by what we see on CPAN).
The point of modularity is to make change easier by hiding implementation details behind an interface. Yet with Moo(se), by default those implementation details are exposed via accessors and the constructor (init_arg's). So to get modularity you have to avoid the defaults, which is tedious and hence very few people seem to do so.
