Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors.

From my own practice, I can't confirm this (and I also heavily disagree with Tadeusz on the topic). When working with my old Moo(se) code, I find it very helpful that the modules have a clear optical distinction between the dumb data (the has () stuff) and the object methods which actually do things (the sub foo { ...; } things). Maintaining that distinction without Moo(se) needs more discipline than I usually have during my hacking nights.

There is some truth in this if the objects are mainly just dumb data containers which don't have methods beyond the accessors. Not having to write code for these is a nice benefit, but you may put this into the category "fancy helpers for constructors". I find these container objects a lot when working with database-heavy stuff. And if the other side is a web application, decent parameter validation makes sense.

I'm using other fancy helpers for constructors like coercion and BUILDARGS almost exclusively when I want to retain the API from a non-Moose constructor to avoid version dependencies.

On the other hand, I have programs where attributes and accessors are almost exclusively used from within the module itself and external uses are through "higher level" functions. For such programs, object inheritance with its method modifiers and in particular roles play a much greater role than the constructor which in itself sometimes is used only internally, exposing factory functions to the outside. Users of these modules (well, mostly I myself) don't even need to know the attributes, but as a developer I'm happy to have them around for debugging.