I agree that CL is very good. It's my first choice for most programs, and I'm familiar with a lot of choices.
CL has one unusual strength that the earlier poster didn't mention: the syntax of CL programs ("Lots of Infernal Stupid Parentheses") makes it extremely easy for CL programs to manipulate CL program source as data (correctly, and without writing a parser). This makes program-writing programs extremely easy to implement. Even lowly one-liner macros end up being much more powerful and useful in CL than one would expect from experience in other languages, and more advanced uses are startlingly powerful. (One common example is to write one's own object system -- inheritance, polymorphism, encapsulation -- from scratch. It's easy to do this in a page or two of CL code, and before CLOS was standardized, it was quite common.)
CL is not perfect, however. It suffers from the usual library weakness of languages with small user communities. The flipside of its dynamic nature -- things like the aforementioned ability to patch running programs -- is that there are various correctness checks and performance optimizations that the compiler can't make. It's pretty efficient, with good native compilers, but for various reasons (including GC and dynamic typing) it can sometimes be anywhere from annoying to impossible to get the last factor of two in portable performance relative to C/C++. And it's a fairly big language, which is pretty common and mostly uncontroversial these days, but which still provokes some friction with people who want something more like the austere elegance of Scheme.
CL also has the weaknesses and strengths of an old language, since it has evolved since the 60s and since it was standardized starting in the 1980s. These weaknesses include various warts in its design (for backwards compatibility or because design tradeoffs looked different in 1987). The strengths include having gotten a lot of things right long ago, like GC by 1970 (?) and lexical closures by the mid-1970s. (It has been sort of interesting watching the semantics of other languages like Perl and Python recapitulate the evolution of Lisp toward GC and lexical closures.)
So for small stable systems where microefficiency is a big issue, I might prefer C or C++ instead; for some things where ML's static type checking model is a good fit I might prefer ML instead (so e.g. I have no trouble understanding why many compiler writers like ML); but mainly I prefer CL. When I don't use CL the usual reason is that I'm working on a problem where suitable libraries or legacy code already exist in another language but not in CL.
Incidentally, for even more free Lisp resources, see www.cliki.net.