Member Rara Avis
When you want to output HTML in a Perl script, you embed the content within the script and then print it as needed. PHP stands for Pre-HTML-Processor and was written by a Perl programmer (in Perl, initially) because he wanted a script language that could be embedded directly in standard web pages. He essentially flipped the flop.
The similarities between Perl and PHP are numerous, both in terms of capability and syntax, which is hardly surprising considering its roots. Not siblings, I would think, but certainly first cousins. I personally think PHP is a little clunky and long-winded, but it's not bad, and hey, most people think Perl is much too terse.
I don't think there are any cons to switching to PHP any more (availability of software compared to Perl was a con at one time, but certainly no longer), and really, none of the pros are issues that couldn't be resolved in favor of Perl. For example, database manipulation is built right into the PHP language and pretty easy to use. It's not built into Perl, but the addition of some good libraries can rectify that. It does, however, obviously require more effort and thought to find those good libraries.
The biggest issue today, I think, is implementation.
By default, Perl runs as a stand-alone processor. Every time a visitor calls a script, Apache shells out to the operating system and runs a new process, with all the attendant memory and overhead that involves. PHP, on the other hand, can be (and usually is) compiled as part of the Apache kernel. There are some alternatives, like mod_perl and FastCGI, that allow one to embed Perl into Apache in a similar manner, but they're not as well supported as PHP and, most importantly, most Perl scripts have to be modified to work under them.
There are some tradeoffs, as always, but essentially today's implementation eliminates a ton of overhead and makes PHP almost ten times faster than native Perl.