Java on the server side usually doesn't have the same kind of sandboxing as Java on the browser, so you have a good point but the comparison for server-side work may not hold. I've often wished I could use Perl on the user's browser rather than JavaScript, ActionScript, or HaXe. One thing that might be nice is if we could have a Perl to Flash compiler similar to what HaXe has.
As for securing Perl more on the server, a perl with a small default @INC can be done easily enough. There are taint mode and Safe.pm to help with boxing in data and code. The installed modules could be kept minimal. Perl supports chroot (although only root can do that).
It should be possible (I'm not saying 'easy') to run both Apache and perl (or Apache with mod_perl) chrooted in the first place if security is at such a high priority. That's a pretty language-independent way to help with security. Things such as ulimit and a good IDS help no matter the language, too.
One thing to keep in mind is that the ability of the programmer to do something doesn't mean it's possible for the site's end user. Any system written in any language which does stupid things with end-user data poses a security risk, no matter the sandbox restrictions. XSS proves the server itself doesn't even have to be vulnerable to cause a security issue -- it can create a security issue for the user even if it is entirely protected.