Hmmm, if one finds doing a JSON-aware guestbook backend for an AJAX website "simple", I don't think such a person should have much trouble finding out what CPAN is, or setting up permissions of paths.

Note that user permissions have nothing to do with Perl, and neither do 500 server errors. But note that '500 Server Error' does have its own entry in perldiag.

Note further that CPAN isn't Perl. CPAN is a user network. Code on it doesn't have Larry permission, nor has it been blessed by the perl-porters. CPAN is not Perl. Repeat. CPAN is not Perl. Nothing can be derived from the existance of code on CPAN. Heck, there's not even a garantee that what is on CPAN is actual Perl code.

I think that if there were a kind of "Training Wheels Perl" environment that included the kinds of things people are doing with Ruby and PHP without too much pain, we would see Perl begin to gain in popularity with the newcomers. Perl could lose that "Difficult" image it has picked up.

So, your conclusion is that having a community that doesn't share code, or makes sharable code hard to find, is actually a good thing? Because it reduces options? Well, I guess it's always possible for a newbie block cpan.org on his/her firewall....

{Setting up a new server} I've streamlined the process a great deal and it still takes a while.

Then you haven't streamlined it enough. It's certainly not Perls task to streamline setting up your server. Most people will want to install many pieces of software that isn't written in Perl anyway. To be able to quickly install a new server, the correct answer is to use a repository, using whatever package manager is appropriate. I use yum and (Solaris) quickstart.

I can imagine what it takes for a newcomer to get up-and-running with some of the more advanced tools like Catalyst + Template + DBIx::Class

Well, they aren't "advanced" for no reason. But how would you solve it? Forbid the existence of Catalyst? Do you have any solutions?