I agree that mod_perl is not appropriate for environments with potentially malicious users in a shared environment; I just don't agree with your reasons. I think they show some common misconceptions about mod_perl, e.g. memory leaks and dangerous apache API. The reason it's unsafe is all on the perl side, i.e. you can mess with other people globals, functions, etc. as much as you want to.

I haven't tried it, but with mod_perl a user ought to be able to modify his/her virtual host document root and mess with other users' stuff

You're thinking of adding things like an access handler or filter to someone else's stuff? You can only change that sort of configuration during startup, which would require you to have admin privileges on the server. After startup, docroot can't be changed.

A user might be able to bypass bandwidth throttling too

If you give people just Apache::Registry access and no use of .htaccess files they would not be able to, since it would be too late in the request for that. They could skip a cleanup or logging handler though.

Would it be impossible for a mod_perl script to persist in the apache child and monitor information passing to and from the sites of other users?

Not really. Your code ends when the request ends. However, you could take advantage of Perl's unprotected nature to globally redefine the print function or change the Apache::Registry handler function to do something completely different. So again, wide open for exploits, but all on the perl side. None of it related directly to the apache API.