Reini Urban's ExtUtils::MakeMaker make release post demonstrates how to add a few of the features of Dist::Zilla to the why-does-this-still-exist ExtUtils::MakeMaker. (Spoiler: it still exists because it's not worth rewriting everything that uses it and continues to work.)
While I think everything about MakeMaker's implementation is blepharitic and, quite likely, contagious, you might find it surprising that I agree in spirit with the point both Reini and educated_foo make in the post and its comments. In summary:
Automating a task is only worthwhile when the benefit of automation outweighs the cost of doing so.
That should be staggeringly obvious to everyone with more than six months of serious programming experience, but it's not.
I spent a few days getting my head around dzil and still haven't updated all of my releasable code to use it because the act of conversion takes a few minutes. If I have no plans to release new versions of that code any time soon, there's little value in performing the conversion. Similarly, if I had a good release strategy in place before dzil came about, the cost of switching would have to be less than the cost of keeping things the same for things to work out. (You can make the same argument about switching between technologies such as languages or editors.)
Sometimes a technology is measurably better. For me, a git-based workflow using dzil beats all of the alternatives I've tried. The same goes for Plack for deployment and cpanminus and perlbrew for managing Perl installations. Yet I happily used Subversion until the pain of managing branches and merges and repositories outweighed the pain of figuring out git.
With that said, Aristotle is right (as usual): automating away all of the
silly little niggly details that are tedious to remember and get right is
almost always worthwhile. Whether that's Reini's EUMM recipe or the dzil
ecosystem depends on who has to automate things. That's the same reason
make test or
dzil test or
prove -lr t/
is much better than scanning the output of multiple test files and trying to
summarize in your mind.
(Fun fact: in my first few public Perl 5 projects I manually removed all of the CVS directories because I didn't know about CVS export, to say nothing of EUMM. In my defense, this was 1998.)
Sometimes you get lucky and find an automation that lets you share smaller pieces of hard work between lots of other people—there's one advantage of dzil over EUMM. Where a user of EUMM might happily copy Reini's code into every Makefile.PL to add those nice features, a dzil user can install a plugin and use it on every project. (... though I didn't see a NYTProf plugin when I looked yesterday, which surprised me.)