This could make sense. In a sufficiently complex language, a single "VM" instruction translates to many native instructions. If you compile a program in such a language into native code, the size of the code explodes, resulting in really poor cache utilization. A tight interpreter on a modern processor (heavy cache fault penalties + branch prediction) can very well perform better than a natively compiled program. Performance is a very tough problem, unfortunately it's very difficult to find a "superior" solution - it just depends on far too many variables.
If memory serves me, there are also cases where information available at run-time can allow better optimizations than could normally be done at compile-time--I think the JVM has some tricks along those lines for JITing bytecode into native instructions, but I suppose the same principle could apply elsewhere.
Nothing stopping you doing these kinds of optimizations on Lisp code again at runtime when you have the extra info. Just automatically recompile if you know it will save you enough time to be worth it (which is a more difficult problem, of course...)
