There are applications where the overhead of compilation on the fly (as opposed to straight interpretation - Perl is not an interpreted language) is unacceptable. For those, you really need a language with low-level constructs that can be compiled to highly optimized, targeted native machine code. That is to say, C or maybe C++. Other languages like Java, C#, VB etc. don't cut it, because you have the overhead of a virtual machine to worry about.

What I'm saying is that although you may see, in some situations, a Java program perform better than a similar Perl program, it's probably not because the Java program is precompiled and stored in bytecode form (this is possible in Perl too, btw, but the feature is considered experimental). I would say that short-running programs might be an exception, but even that exception is limited by two factors: 1) until recently Java VMs had such poor startup time that the advantage of not having to compile source code was largely lost, and 2) in both Perl and Java you can create frameworks like mod_perl that allow a piece of code to be run repeatedly in what appear to be separate instances of the program but aren't really.

Now, if you were talking about an actual interpreted language like shell, awk, etc., that would be different. There the overhead of the interpreter slows down the program considerably, because it literally has to analyze each chunk of code before executing it.