I believe the whole point was to target the JVM, because of reuse and maturity. And actually it's not stuck just in java ecosystem, clojure got wings years ago. Yoy can find it inside a browser today too :)
I wonder if there ever has been talk of a native Clojure? I guess it may not be very usable without the JVM ecosystem, though. Frankly, I find calling JVM library calls from Clojure to be quite ugly and really stand out in the code (mostly because of the mix of the lower-case-dash-delimited variable and fn nameing convention of Clojure and the mixed-case/camelCase naming style of Java.
The problem with all languages that decide to implement their own runtime, instead of building it on top of JVM or .NET eco-systems is that their native code generation and GC implementation are always going to be worse.
Also there is the issue of having to implement the whole set of third party libraries from scratch, just like PyPy and JRuby have issues using libraries that rely on CPython or Ruby FFI.
So unless you get a set of developers really committed to go through the efforts of making it succeed, everyone will ignore it.
The closest thing to a native Clojure is Pixie[1]. As the authors note, it's a "Clojure inspired lisp", not a "Clojure Dialect".
>Pixie implements its own virtual machine. It does not run on the JVM, CLR or Python VM. It implements its own bytecode, has its own GC and JIT. And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable.
