I would actually recommend watching the entire youtube video I posted earlier (Clojure for Lisp programmers). Rich talks about a lot of the design decisions that went into Clojure. Some decisions I agree with, some I don't, but there was thought into creating a unified whole and he was clearly aware of work that had gone before, even when he chose to do things differently.
Note also that Clojure was his third attempt at doing a lisp/java interop, so there was a lot of previous experience backing many of those decisions.
Lastly, it's really easy to make a bad lisp-frontend for a language and a massive amount of work to make a good one. This is well known by anyone who has been in the lisp community for a while (if for no other reason than they themselves have made a bad one) so for better or worse, such frontends tend to be ignored.
The compiler could itself be written in its own target dialect, and bootstrapped with some existing Lisp.
Some random thoughts on why this matters:
Clojure is very much not a thin s-expression layer for java; that would have been terrible (Python is more like lisp than java which is why Hy is tenable whatsoever).
In particular, CL style macros with out some first-class concept of symbols are a footgun[1], but I'm sure I could find other issues.
Another item that can't be ignored is that Hy selected the clojure syntax, which is going to be a turn-off for anyone coming from Lisp or Scheme.
Finally, there are hundreds of thin s-expression layers on top of existing languages, and most of them are terrible; Hy has done nothing to stand out from this crowd, so most lispers will not look closely at it.
1: See https://youtu.be/cPNkH-7PRTk?t=4786 for Rich's discussion of how he managed this issue in Clojure.