I like using CL when I know that I don't need scalability and when I know that I'll be the only developer of the program that I'm writing. Under these circumstances, I enjoy it very much because it caters for this setting.
And I'd like it with scalability too, how about that? The "only developer" part I simply do not get. What is the deal with the solitary state here?
My personal conclusion, having used Lisp for many years, is that it caters very well for the individual. After all, REPL based, exploratory programming is all about the interaction of an individual with the machine. This nature of Lisp goes far, and then Lisp itself wants to be explored. As an individual programmer, Lisp provides me not only with a set of tooling that I know how to use, it also provides me with its own exploratory space: There is this set of Lisp features that I have not found a good use in the past, but that I would like to try out in the future. Now, this might not be that far from other large languages, yet due to the fact that Lisp carries a lot of baggage from older Lisp dialects, a lot of these seldom-used features would not have made it into a new language, had it not been to appease different parts of the language committee who had their own baggage to carry over into the new, unified Common Lisp dialect.
As an example, I would like to point at symbol plists, which were integral to earlier LISPs lacking better, dictionary-like data structures. They sleep dormant in the spec, but rest assured: If Common Lisp is your community, you will eventually run into someone who insists that symbol plists are great and uses them all over. Looking at you, Ken.
Now, this is all good and fine for the solitary experience of having a tool that you can both use to create solutions and that is in itself something that you can endlessly explore. It is less useful in the world of industrial software development, where maintainability of systems written by other people is one of the key properties that should be supported by the implementation language. While this usually makes languages boring and often causes features that "one" would "like" to to have be missing, it also is a property that makes one language successful and the other language less so.
This is also where scalability comes into play, and that word certainly needs to be qualified before it can be discussed. If scalability simply describes the raw size of the problem that can be addressed with a tool, then there are limits to what a given language can do based on its inherent support for threads that execute in parallel. Parallelism is something that requires proper abstractions. Some say that these can be just on the library level, but my experience tells me a different story. I find it difficult to create robust parallel solutions in languages like Lisp, as the language itself assumes a single thread of control in how it makes variable bindings accessible and how information is passed between invocations of functions by reference.
If scalability is about the number of people that one can bring into a team that develops a single system, Common Lisp is not a particular nice environment either. Due to its size, age and heritage, every program that is written in it basically subsets the language and, worse, often also extends it because the subset was found to be insufficient and extending the language is easy. The result is that unless a new person has already mastered a lot of Common Lisp, they will usually have a hard time finding their way around in a new system.
This is not to say that the Common Lisp is the only language with that problem - It is a property of many old languages. I would still argue that CL is particularly affected because it was an amalgam of several languages to begin with, because it had very strict performance goals in the beginning and because the model of development that it always catered for is not that of a team, but that of a person interacting with a long-running program.
-Hans