|There's more than one way to do things|
I don't exactly know. I have been wondering about the same questions a lot (having some, but not much PHP experience) but whenever I asked, I got this same reply: Perl as a language is much more complex than PHP so it would be impossible to stop someone from stepping on someone else's toes.
My idea was that given Safe, that should be possible.
I have repeatedly wondered about the dangers PHP exposes a site in shared hosting to on other levels. I have been bitten by mod_cgi in a shared environment before, so I'm aware that there are many ways to interact with someone else's data and/or code under these circumstances. For the relatively trivial mod_cgi environment there is suEXEC which, with some care in setting up permissions, can effectively and completely cage in everyone. But so far I've not seen much about the topic where PHP is concerned. In the case of mod_perl in its current forum it is at least known that one needs one Apache per user to make sure they play nice.
As for not paying a nickel because it requires you to run in a compartment: the idea is that you have enough freedom within this compartment that you don't notice. That should be doable at least for Apache::Registry scripts.
The market for this would be the same folks who buy PHP-enabled hosting and a PHP application to install on it and have little to no interest in developing that kind of solution on their own. The market, in other words, that is nowadays covered mostly by PHP.
Certainly you won't use it for custom applications relying on "advanced" features, but I think that if there was a low-end mod_perl market (even just a crippled version), there would be a larger high-end market as well and, most importantly, there would be more mod_perl solutions.
Makeshifts last the longest.