Lisp doesn't work well without a good IDE...and I don't count EMACS.
Racket would be ok. It has a decent IDE. But it doesn't do multi-processing, even though it has the appropriate language features.
I don't know Clojure well enough. The last time I tried it (over a year ago) the install instructions produced an only-partially-working result. This is probably NetBeans fault rather than Clojure, but I didn't follow this up. I never got as far as checking how it did on parallel processing.
Most Scheme's and most Lisps don't handle Unicode gracefully.
I've considered Lisp several times, and always found some reason, not always the same, why it was not satisfactory. Most of them weren't inherent in the language, but in the state of the libraries or of the development environment.
P.S.: For Python, Ruby, Vala, etc. I don't feel the need of an IDE. For Java one is highly desireable. For Lisp it's essential. This largely has to do with the state of the libraries and the documentation....but it also has to do with the size of the active namespace (and how familiar I am with it).
P.P.S.: If you're going to depend on a set of public libraries instead of an included set, they you had better verify them for quality. This is why Python's "batteries included" stance is so good. You can depend on the basic libraries. Ruby tries to handle this with Ruby gems. The quality isn't as good as Python, but it's pretty good, and it has wide coverage. Lisp....The public Lisp libraries often don't work as advertised. It appears as if anyone can add anything to the library collection without any quality control. D also has that problem. It's one of my favorite languages, but it's collection of libraries is abyssmal. Often they will only work with an old or new version, but the requirements aren't usually listed. Frequently they have dependencies that aren't listed.