I have a couple of disconnected thoughts on this ...

First of all, it's a very good idea to treat – and therefore to package – a Perl-based website application as a distribution. In other words, do all of the stuff that CPAN packages do to automatically satisfy whatever dependencies there might be. (And to automatically discover them, as you are building your distro. O'Reilly's Intermediate Perl book has a pretty good, albeit short, section on this... for those of us who still like to read paper.)

Second, “all I can say is that I have made a very good living lately, replacing PHP and encouraging people not to use it” ... even though, of course, I still do a fair amount of PHP coding myself, because you inherit what you inherit.

Your “bologna” analogy is a very good one. (I'll take my London Broil medium-rare. Now that you've made me hungry, at eight o'clock in the morning, “is it ready yet?”) It reminds me of what they say in the very-excellent book, In Defense of Food. PHP is like what they call “a food-like product.” So is bologna.

The essential drawback of PHP lies in its stated design:   it is built to embed functional logic into an HTML page. Everything about that language is really geared toward the generation of HTML output (one way or the other...) to insert it into a surrounding HTML page. Presentation and logic are therefore inextricably linked. Furthermore, both presentation and logic are also tightly coupled to the underlying (SQL) database. What results is a very quickly-built, but very short-lived “application” that costs many thousands of dollars.

There are gobs and gobs of “newbies” out there right now, churning out just such applications, and managing to disappear before they have to start maintaining them. It's impossible to maintain profitability when the shiny new car that these guys sold them winds up being in the shop every few weeks or months. So they abandon that car and that client and go searching for another car to build. Word gets around, though. (Just how many Drupal hacks does one town really need?)

PHP is “easy to deploy” because so much is built right into the executable:   pragmatically, it has to be. You've got a library of hundreds of built-in functions, whether you want them or not. You've got “one way to do it, and if you don't like the one way that PHP has to do it, you have to change what you do. For a business, that's not good.

In the real world:

1. Web-sites do not exist in a vacuum. They are part of a much larger system.
2. Web sites must not be tightly-coupled to the underlying database.
3. Nothing is really CRUD.
4. Very quickly, we see that we are having to deal with many more types of interaction than “just HTML,” to many more types of devices than “just web-browsers running on laptop computers.”
5. So, if presentation is tightly-coupled to everything else, you're already dead.

Suddenly, the very designed-in characteristics that make PHP-based development “easy” also conspire to sabotage the shelf-life and the maintainability of the applications that are built in it. Mind you, I'm not slamming PHP when I say that:   PHP was designed as it was designed, by “good and competent workmen,” to be a power-tool for the then-prevailing conditions. But those prevailing conditions have since changed. The very same design decisions that were so vital to allowing PHP to accomplish its mission then, have now become a box.

The more you look at Perl, and especially Moose.pm and the forthcoming Perl-6, the more you come to understand that you could literally spend years plumbing its depths. It just doesn't come with a marketing-department.

I'm building “a web-site, among other things,” now that is aggressively built on (Moose-based) Perl objects. The web-site is strictly just a surface-layer; nothing more than presentation, and it's only one of the several types of presentation that must be available. Because I do not have the time to build, let alone to maintain, any such thing, the corresponding design is extremely orthagonal. Presentation, logic, and data persistence are widely separated. While it took many more weeks to “achieve lift-off” than I had expected it to do, let's just say that it did not leave any pieces of its landing-gear on the runway. I can't do that in PHP. I can't even come close to doing all that needs to be done, in the very-short amount of time available to do it, at the speed it needs (no time to snooze waiting for a JRE...), with anything other than Perl.

But the final deployment does need to be “a distribution package.” That's an extra step, but well worth it. Deploying the final product onto a web-server needs to be a hands-off repeatable process just like going to CPAN and saying install my_stunning_app, and it needs to avail itself of the same (existing) techniques.