Yes, Clojure isn't exactly like older Lisps. Why should it be? Those Lisps are all different from each other as well. If new Lisps can't introduce new ideas, what is the point?
But I would describe Clojure as "not Lispy" because its behavior seem to fall into the compilation idea more than the interpretive idea. I would execute `lein run` and a failure would drop me out into the Linux shell. An equivalent command in CL would throw a condition and drop me into an interactive mode to patch it up. I fully acknowledge that my tool use may not have been ideal, of course. But my Clojure was giving me a compile-run-test cycle as opposed to the the interactive editor/repl cycle of CL. Errors in the source would cause exceptions and crashing in the compile phase; errors in the runtime would cause a crash.
I want to hone in on the second point you made, in terms of new ideas. New ideas are good (c.f., Kernel). New ideas should be aggressively pursued. I draw the line when someone has a slightly varied idea and wants to fork out something & get a community going just for that slight variance. That's just annoying and forks effort. If the new idea is really radical and can't be reconciled with extant tools, of course it deserves to be a new thing. Lisps are an insanely awesome tool for exploring semantics and I hope they keep getting created and churned on for decades to come. I just hope that the ideas which are reconcilable to production systems are reconciled so that we don't fragment further.
Porting code between these is relatively easy or even trivial when only the core is used.
[1] This is the hard to explain part.