PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.

PHP code gets embedded into HTML pages, unlike Perl. This makes it very fast to code web pages and fast to deploy a new site, thus speeding up Web development and lowering overall cost of ownership. An important code management technique for programmers is separating code from data. This allows us to make changes to the code or data without affecting the other. PHP uses the tags to indicate "code inside". In Perl, however, programmers are encouraged to use print statements to generate the HTML. True it is possible to implement templates in Perl (with more difficulty than in PHP) to separate code and HTML, but 90% of sample Perl code on the web doesn't do that.

PHP is secure. Perl scripts tend to have more security holes. This is because PHP has built-in a lot of the internal operations of dealing with web page requests and serving information.

PHP is easy to learn in comparison to Perl. It's easier to learn than C, Python, Java, and most other programming languages used in web development, for that matter. The Perl style of programming is unique, and thus not universally applicable to or from other programming languages. Accessing web form variables in PHP is straightforward, but in Perl requires either detailed knowledge of either HTTP header formats or one of many Perl CGI libraries.

PHP takes less "overhead" than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you'll be able to handle more simultaneous users on your site. Benchmarking tests show time and again that PHP runs faster than other web programming languages. Check out these benchmarking analyses done by major computing magazines.

Hm. Most of your points seem to come from an incomplete understanding of Perl. Let me address a couple of big ones:

PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.

Perl's database capabilities are impressive. DBI is a flexible system that supports Oracle, MySQL, Sybase, any ODBC source, and many more. Built upon it are things like the DBIx family of modules that allow for robust database access without writing SQL.

Perl may not have had database support early in its life, but as it currently stands, its support is much more mature and robust than PHP's.

In Perl, however, programmers are encouraged to use print statements to generate the HTML. True it is possible to implement templates in Perl (with more difficulty than in PHP) to separate code and HTML, but 90% of sample Perl code on the web doesn't do that.

Programmers are most decidedly not encouraged to use print statements to generate HTML. Programmers are encouraged to use Template Toolkit, HTML::Template, or other easy-to-use templating systems. Of course, Perl lets developers shoot themeselves in the foot -- but so does PHP.

Later in the same point, you say "An important code management technique for programmers is separating code from data", and templating systems do that. Marking PHP code between <? and ?> is not separation of code and data -- it's inclusion of code (PHP) in data (HTML markup).

Observe:

<p>This is a paragraph with some <? print($generated_content) ?> in PH+P.</p>

That's a placeholder for code to act on. And that's separation of code and data.

Perl scripts tend to have more security holes. This is because PHP has built-in a lot of the internal operations of dealing with web page requests and serving information.

True, PHP has web functionality in the core language since it was developed with the intent of being a web language. However, to suggest that dealing with page requests and serving information is something that each Perl developer has to deal with in their own way is naive. Included with every modern Perl distribution (that is, it's in the Perl core) is the CGI framework, which handles all of the web-request architecture. Trivially available from CPAN are such things as CGI::Application, CGI::Simple, the FastCGI extensions, even complete web-application frameworks like Mason and Catalyst.

PHP is easy to learn in comparison to Perl. ... The Perl style of programming is unique, and thus not universally applicable to or from other programming languages.

PHP was developed with much of the Perl style in mind, and the styles between the two are very similar. PHP does allow a new developer to go from zero to web-enabled app very quickly (which has a lot to do with it's popularity for web apps, no doubt). However, nothing about PHP makes it easier to write good applications when compared to any other language.

Perl's style of programming isn't that unique -- it's largely an amalgam of elements from various well-established languages. Perl was one of the first languages I learned, and I found that picking up PHP, Python, Java, and even C were made quite easy with a foundation in Perl. This is because these languages borrow from each other significantly.

Accessing web form variables in PHP is straightforward, but in Perl requires either detailed knowledge of either HTTP header formats or one of many Perl CGI libraries.

Accessing web form variables in Perl is easy and straightforward as well. Perl was designed to be an all-purpose language, so yet you have to use a CGI module. But there isn't a whole lot of knowledge involved. Check it out:

That's just entirely a red herring. Consistency and modularity are no more difficult in Perl than in PHP (or vice-versa). It's up to each developer to be consistent and modular, and it has almost nothing to do with the language choice.

PHP does have some advantages over Perl for certain applications: for example, mod_php is ubiquitously available from inexpensive virtual-hosting providers compared to mod_perl. It is certainly worth comparing the languages in terms of when each is the best choice.

However, to simply assert that PHP is a better language than Perl is naive. Specifically, the justifications for that assertion that you supply above are ill-concieved.

Depends on the POV. If you're a programmer, sure Perl gives you better tools, if you're not biased. If you're just a wannawebpage newbie, things like lexical scoping with my, closures, map, grep, contexts and alike are things you can't imagine to be useful. You just want HTML escaping, mysql (and all other supported database drivers) all other tools you use stuffed right into the namespace of your mywebpage.php4.

Sure PHP has bigger usages and *is* and *can* be professionally used. But in my view that's neither the majority nor the part that started this hype.

It's just that PHP is neither: Half as bad as many people say it is - especially since PHP 5

Well, IIRC there are still no namespaces, it's still thousands of functions from hundreds of libraries I did not invite partying in my basement. The calling conventions are still organized like Alice's wonderland and there are no closure-like things. Calling "call_user_func" with an array just doesn't count :)

Of course, it's still a question on how to define "bad." It's surely not bad per se, as nothing is, but it is for me personally for a number of reasons (some stated above).

I don't know that it's a good or a bad thing; the point appears to be that if it's easier, more people will want to try it, regardless of whether it's better (or even acceptable). It's kind of like looking for your lost wallet under a streetlight (even though that's not where you lost it), because there's more light there. So, even though PHP may not be a good candidate for certain tasks, people may prefer it because it's easier to use for some purposes.