If there's a debate between embracing the CPAN and relentlessly avoiding dependencies, my taste runs toward the former. Certainly avoiding unnecessary dependencies is a valid strategy, but no other reason for avoiding useful dependencies argues, in general, more strongly than the reasons for using dependencies.
Consider some of the most successful CPAN distributions: DBI, DateTime, and Test::Builder. On their
own, they provide many more features than most projects ever need (I care
mostly about PostgreSQL access, continental US time zones and holiday
schedules, and often only a handful of
Test::* modules). I could
probably reimplement most of the code I need myself with fewer
abstractions unnecessary for my needs, less code overall, and increased ease of
installation for the users of my software, but I don't. Probably neither do
most of you.
I see Moose the same way. So do some of you. While I could write an object system myself (I've contributed to a few on projects you've heard of), it's not worth my time to do so when a perfectly good system already exists—a better system than I'm likely to write, given the time I have available.
More than that, installation is once, but sharing is caring forever.
In other words, the hassle of figuring out how to bundle or mark for installation one or more dependencies is a single cost. The maintenance burden of my reinvented libraries lasts as long as I allow those reinventions to exist. If my users are capable of using a custom CPAN (or CPAN itself) to install my software as bundled for the CPAN, dependency management has almost solved itself. The whole of the CPAN ecosystem, including testers and platform smokes and bug tracking, supports those dependencies.
I can release my own reinventions to the CPAN to take some advantage of these network effects, but compare the contributor lists to the three distributions I mentioned to the contributor lists of single-use distributions. The correlation exists: the more widely used a dependency, the better chances of it meeting user needs. The more users (and the more diverse users), the more chances to find bugs and infelicities. (You can make the case that CPAN Testers could use rigorious stochastic analysis to improve the confidence and utility of its coverage, but the world of free software tends to work best when it trades small amounts of volunteer labor, properly applied, for trivial problems.)
This is not an absolute guarantee, of course. For example, security flaws may exist in a widely used dependency where a careful reimplementation may avoid the problem&mdash. Best judgment applies, but, ceteris paribus, I trust a project more upon learning that it does one or two things well instead of attempting to do everything itself.