Sure. Obviously compiled languages still beat out interpreted languages in terms of speed and memory consumption any day of the week. Of course, these days most compilers use a multi-phased approach that involves some kind of intermediate representation. The genius of technologies like JVML, .NET CLR, and Parrot (and their less widely known predecessors) is that this intermediate representation can act as a portable bytecode in itself. This is why you can run Java on PDA's but not Perl (at least not until the release of Ponie): Perl requires a full-fledged interpreter which is just too much overhead for a small system like that.
But a web application is different. There you tend to have heftier CPUs and large bundles of RAM. If there is a CPU bottleneck on that kind of application, it will likely be because of intensive database queries or on-the-fly calculations, and not the interpreter. That said, if you were to write a web app in C or C++ I'm sure it would be much faster.
The catch is, of course, that almost no one does that, because it's generally felt to be not worth the effort. They write web apps in Perl, Python, PHP, ASP, Java, ASP.NET, etc. The reason Perl does not suffer a major performance hit compared to Java and .NET merely because of a lack of compiled bytecode is that, assuming you're using mod_perl with either direct handlers or Apache::Registry scripts, the interpreter compiles and loads each module into memory only once. This one-time cost is higher for Perl because it has to compile the source code, but it's hugely different from doing it for every page hit.
It's also possible that whoever told you this is conveniently ignoring the existince of mod_perl (and mod_python, etc) and presuming that all Perl web apps run as straight CGI, which is patently unfair.