I think you are assuming that the person on the downloading side is someone understands that Perl has command line options beyond "perl myscript", knows how to find and read perlrun, isn't scared to use options other than the script name or -mSome::Module, and knows how the command line options interacts with CPAN::Config, assuming they even know there is a CPAN::Config . That is likely true for a command-line comfortable developer who is selecting modules for a project, but not necessarily for someone just looking for a ready-made bit of functionality to use on their website.
Nor is it necessary true for an experienced developer who "grew up" using GUI development tools and only occassionally uses Perl. The mechanics of turning code into software is often a mystery to them, some sort of black magic that happens when they click the build button. Even the need for a "make" program is confusing because they have no real understanding of how the process happens without a GUI.
However, it comes down to philosophy - should our goal be to make a package that can be installed without a burp for someone who thinks everthing should be point and click (or command w/o options and enter) or should it be aimed only at people who are agile at the command line and comfortable looking up command line options?
I think you are assuming that the person ... should it be aimed only at people who are agile at the command line and comfortable looking up command line options?
What are you talking about? Either your target audience can create perl modules or they literally don't know anything about perl. Your claim your audience is the former, so why worry about some hypothetical newbie who only knows GUIs?
For my particualar module, the audience is programmers. I doubt anyone who isn't an experienced Perl programmer cares one whit about what sort of exception they use.
However, this is a tutorial. It needs to consider other sorts of programs, not just my particualar one. It also needs to consider the views of the community and not just personal agendas.
Some software is written for people who program. Some software is written for people who merely want to use it. All they know is that they have to run the script using a perl interpreter. PHP, C, Java all support applications written for both communities. Should Perl be different?
My sense is that the Perl community is divided on this issue. There are some people think Perl should be a language for programmers by programmers and that all modules should either be installed by programmers or people who are willing to learn some of the skills of programmers. For this portion of the community, the idea of a makeless build is silly.
There are others who would like to see Perl attract a wider audience that included non-programmers, developers who think build is a GUI button, and people who just want drop-in functionality on their website or desktop. If this is a goal, making make a prerequiste to downloading CPAN modules is an impediment. You don't need make to write Perl programs. You don't need make to use Perl programs. You don't even need make to copy scripts from one place to another nor to run tests, so why require it? It is like insisting that everyone who wants to eat cheese go out and buy a diamond cutter. It doesn't make the cheese taste better and it gets in the way of eating cheese.
My own views are in the second camp. I would like to see Perl software be readily available to the widest audience possible. However, that is immaterial to this tutorial.
In the tutorial the views expressed about portability were culled from a number of sources both within and without the Perl community. The portability issues of make have been a concern for sometime even within the *nix community. GNU jumps through hoops to make sure its software can be reliably built on multiple platforms using make. Ant, used by the Java community, was in part a response to portability issues related to make/nmake/dmake. Those responsible for the Perl itself were persuaded that this was a legitimate enough issue that they included an option for make-less builds via Module::Build in the Perl core. I would be remiss not to mention the portibility issues, even if I thought they were totally stupid. (Note: my personal view is that for C/C++ compilation we still don't have a better tool, so make stands as the tool of choice regardless of difficulties)
A more reasonable complaint would be something like this: your discussion of CPAN module development is too biased towards pure Perl modules. This tutorial does not address the needs of XS module builders for whom make is still the gold standard.