You're half right. Tuned Lisp code can be as fast as C, but you have to know the compiler so intimately that you can tell what kind of machine insturctions it is generating; you'll use "disassemble" a lot ("disassemble" is a part of CommonLisp standard---you may get a sense how Lispers are performance freak). Usually the bottleneck part is tuned to the point that it won't do any allocation and run-time type dispatch at all.

There's one big advantage of using Lisp over C for performance: Macros. During optimization it is typical that you have to write several versions of code, changing bits and pieces, and run benchmarks to see what is optimal. Macros allow you to generate different versions of code from simple changes of parameters, without incurring overhead of function call/variable reference etc. (You can do similar thing in C++ templates, but Lisp macros allows much more). If you can easily parameterize your code, you can try more ideas and run more benchmarks, so it is more likely that you'll find better optimization.

AN example: Allegro CL version 7 and later has Perl-compatible regular expression library, purely written in Lisp, that runs faster than Perl (at least at the moment I wrote it, using benchmark suite came with PCRE).

Lisp is compiled, not interpreted, most of the time. No one uses interpreted Lisp in production; it's all compiled. And it's compiled to very fast code, much of the time, particularly when you add type declarations.