Why Clojure over other JVM Lisps: Kawa, Armed Bear or SISC?
Solution 1:
Kawa, ABCL, and SISC are reimplementations of existing languages that are quite long in the tooth. They are excellent if for some reason you want to use standard Scheme or standard Common Lisp on the JVM.
Clojure is a new language. It doesn't fill a gap. It adds entirely new possibilities. It favors a purely functional approach- Scheme and CL are both multi-paradigm. Clojure borrows heavily from the design of various FP languages (ML, Haskell).
And yes you could add concurrency support to other Lisps, but that's entirely missing the point. Clojure was designed from the very beginning as concurrent language. So much so that writing concurrent programs is trivial in Clojure - not rocket science as it is in non-functional languages (Scheme, CL not excluded). Look at this way:
People say that C lets you write fast programs by default.
Well, Clojure lets you write concurrent programs by default.
Solution 2:
"Clojure is a Lisp not constrained by backwards compatibility" (that's from the Clojure website). It's a fresh start. It's progress. Use the ideas that make Lisp/Scheme powerful but rethink them around the Java platform.
Clojure will always be the most recent Clojure. With any other language ported to the JVM, the JVM version might always be playing catch-up. If you don't need the Java Platform why use SISC over another Scheme? If you do, why not use the one Lisp (Clojure) that was designed specifically for it?
Designed with concurrency in mind.
Solution 3:
The most simple answer I can come up with is, Clojure is not Common-Lisp. Clojure is not constrained by the history of other Lisps. It is a new language built for the JVM.
Solution 4:
I simply wasn't aware of those, which is a serious benefit for Clojure (that people made enough noise I found out). The biggest thing Clojure has that I didn't see in those you listed is Software Transactional Memory.
Clojure was also designed for the JVM, as opposed to being a layer for another language, so it's a little more "Java-y" that I imagine the others would be when you have to do interoperation.