Facts:

• PHP is a language
  
• mod_perl exposes the Apache API and is not a language
  
• PHP is for building applications
  
• mod_perl is the engine that drives applications, but it offers no help in the application building process.
  
• PHP runs under IIS and Apache
  
• mod_perl runs only under Apache
  
• PHP has a single voice documentation that covers all aspects of the language.
  
• mod_perl has multiple voice documentation that covers all all aspects of the system.
  
• PHP applications don't require modification to the httpd.conf (PHP requires the addition of the AddHandler for .php files however)
  
• Application frame works for mod_perl (Apache::ASP, Embperl, Mason etc.) require modification of the httpd.conf

These are just some of the issues surrounding acceptance of mod_perl over PHP. Combining mod_perl with Safe doesn't eliminate the learning curve that mod_perl has, not to mention the difficulty in picking the best templating/framework system to use in conjunction with it. mod_perl offers more flexibility, but at the cost of increasing complexity. In environments where the skill level of the implementor is unknown, such as shared hosting there are far too many support and configuration issues to make mod_perl parctical for most business models. Companies that offer mod_perl hosting specialize in it.

So while I agree that Safe might help, I think we have bigger fish to fry.