(1) Lisp can be used in a functional fashion, but it is not a "pure" functional language.

(2) Lisp can be optimized to machine detail, just as C is (up to the capabilities of the compilers -- which for most purposes is sufficiently well-done by Lisp compilers). (See the back of Practical Common Lisp by Peter Siebel, I think it is available online).

(3) Some would argue that writing a program in C is the same sort of pre-mature optimization you refer to. Harken back to the idea of C as glorified assembly code. Solve the same program in Lisp (or another "very" high level language). Profile. Optimize the critical sections (algorithm first, then machine specifics -- which, as I mention in point (1) can be done in Lisp). Voila.

Of course, many "very" high level languages allow interfacing to C for speed critical sections. So, you could apply the same process from (3) with Perl, Python, etc.

A better criticism of Lisp is getting your hands on convenient libraries for some common tasks. However, there are good libraries out there.

For the record, I'm a much better, much more experienced C programmer than I am a Lisp coder.

MapReduce?

Granted, I'm answering a slightly different question: where has FP proved to be a very useful paradigm for solving an important problem. I won't make any claims about optimality.