I've been a Clojure dev full time for a few years, and last year I looked into Haskell quite a bit [1]. But ultimately the fact that Clojure can do live-programming is what really kept me preferring Clojure. And I'm not even talking about that figwheel stuff. I mean just being able to mess around inside the JVM live from an Emacs buffer via Cider, and reloading parts of my code while my app is still running during development. I'm not interested in giving that up, it's made me more productive than I thought I could ever be.
Live coding with ClojureScript/Reagent/Re-frame/Figwheel/REPL is a holy-grail-kind of dev experience for me (and React really does feel like it was ported to JS from a better place), but one has to admit the potential maintainability/refactorability issues when projects grow beyond a certain size (as compared to something like Haskell or PureScript).
Plumatic Schema [1] goes a long way towards narrowing that gap though and I cannot recommend it enough. Whether it goes far enough in terms of safety is certainly a matter of project type/size and personal preference, but to me, for my kind of work so far it does and they'll take away my ClojureScript when they pry it from my cold, dead hands. :)
Also (and slightly off-topic) the combination of clairvoyant + re-frame-tracer [2][3] (+[4] for some minor, so far mostly React Native-relevant additions) should be way more popular than it seems to be. It's definitely one of the most important tools in my toolbox and completely changed the way I approach debugging.
You can do that in Haskell as well though [0]. With ghci, making a code change is almost instantaneous even for big code bases, and you are assured that your code is self consistent. Then mess with your long-running state all you want.
At least for backend stuff, this is no worse than Clojure.
Give it a try :) Ping me if you have any questions.
This is one part of the CLJS story that I think prevented it from becoming more widespread - it lacked a good REPL/compile story for a long time because of closure compiler. I would almost characterize that decision as a premature optimization - they focused on producing small output from the start, IMO larger JS size wouldn't matter that much in majority of use cases (you won't use CLJS to write websites, and webapps can tolerate few hundred k or even a MB of JS that's easy to cache), but they gave up one of the signature strong points for CLJ/Lisp so it wasn't as attractive even to CLJ devs.
(it's a joke)