The sheer ease of slapping a few random PHP tags into an HTML page and calling it "good" instead of having to actually write a program is definitely a factor, yes. That draws in all the web designers, managers, and other people who want to have a page that does more than just sit there, but don't think of themselves as "programmers".

There are also significant historical issues, though, which may be more significant.

By its very nature, CGI is (relatively) slow, because it needs to fire up a new process to handle each incoming request. Back in The Early Days, Perl and CGI came to be nearly synonymous - an entanglement which persists to this day. (Some job boards don't even have plain "Perl" listings, only "Perl/CGI".)

mod_perl deals with this performance issue, of course, but that opens up a whole other can of worms in shared or managed hosting environments, because installing a new module (such as a mod_perl-based application) traditionally requires editing the apache configuration and you can't let all the end users have that power. So, on most sites, Perl was stuck with using slow CGI.

Then along comes PHP, which is not only mindlessly easy to code for, but it also only requires a single module - mod_php - to be installed and all your users can get the speed benefit of an in-process interpreter instead of having to fire up processes through CGI, without having to give them administrative control over the web server process. It's easy to see why it took off like a rocket.

IMO, if we want to see Perl make a comeback in the web application space, the association of "Perl = CGI = slow" is an even more important problem to overcome than any perceptions about ease of use.