He's actually fairly representative of the clojure community in that respect, which is just another reason it's a pleasure to develop in.
I have my concerns about om-next, but overall since I'm writing a complex side-project, it's worth it. If I had to ship something tomorrow, I'd go with reagent still, but for longer projects where you can spend more time and get over some learning curve and alpha/beta type bugs, om-next is a good fit for large projects. I found reframe to be generally the best way of working with reagent, but not as good when I had lots of chained events and complex queries. I spent a lot of time optimizing around some ways that reagent/reframe does things where as in om-next, I could tweak things more to my needs. Om-next also offers some additional features many people don't need, but fit my use-cases well (ex: server-story, pulling only what you need, normalizing client app db data).
To summarize, reframe is a nice framework and really great for small projects or projects that need to ship today. It works and is the best approach I've seen on top of reagent (and react). Om-next is good for people that can afford to take some risks and have complex requirements but still want a proper framework on top of react. Om-next will make you do a lot more work up-front and has a lot more ceremony, but there is a reason it exists. Generally, I have found om-next powerful once you are able to grasp the way it wants you to do things. For people who want something like reframe like om-next, there is the "untangled" framework. Anyway, I wouldn't recommend om-next or reframe/reagent over the other, rather I'd suggest either and match your requirements accordingly.
In the second, I'm using a bit of Datomic mainly to save UI-related and small bits of user state. Mainly I use Cassandra, Redis, Kafka, and Elasticsearch. I should add in this project, I'm also using untangled.
I communicate a lot over websockets as well, so between that and Cassandra I have to do a lot of mapping and transformations on my own, however once you get it setup the rest is mostly magic. Most of my reads and writes over the socket are happening with consumers and producers to Kafka so mapping om-next data here is just standard Clojure, nothing fancy.
When I do query Cassandra directly, the queries in particular by nature need to be somewhat restrictive which it turns out play nicely with om-next since mostly for reads I just need to worry about the "select" columns. Redis I just use for LRU caching and to buffer some video-like blocks of data before the user tries to access them. Elasticsearch is just used for searches and some type of filtering, but gets populated through Cassandra data anyway so again no problem with om-next.
I'd say the most annoying thing here was as I hinted, getting it all setup. Things are clearly built for Datomic, but there are integration points all over the place and just using standard functions in Clojure to manipulate vectors and maps is easy. If you're not experienced with datalog or datomic pull syntax, things might be a bit harder at the start for some people.
Regarding API calls, I should add since I am using untangled, I use the default websocket lib which is just sente. I have rigged things up with aleph and yada, but also played around with standard compojure api and other offerings. Long-term I'd like to stick with yada, but I've encountered some documented bugs that are annoying so I've put my focus elsewhere in the short-term when needed.
Code here: https://github.com/rahulpilani/mort-calc
Elm is very nice but definitely has a learning curve. You can try Elm in a low impact way by making a small component with it and using it alongside either React or Angular ( or in other scenarios as well ). It can also work as a state management solution for parts of your front end app. On the other hand building an entire SPA in Elm is a monumental task and requires significant investment. As the Elm experts say Elm is not really a good solution for quick one offs or prototyping. It may require you to reinvent the wheel for many widgets for which you could find relatively high quality open source options in React or Angular. Also, Elms JS interop is a bit tedious at times but works relatively well.
Clojurescript has been around longer then Elm and for most has less of a learning curve, but for some the JVM tooling may be a turn off. Nonetheless it is fun to use and there are several Clojurescript UI libraries (Rum, Reagent, Om, Hoplon/Javelin) all of which are used in production at various places.
Of course even today I miss out on react components on npm (having to first port them to cljsjs) which is a source of slowdown for me personally.
- creating a project from scratch is easy: lein new reagent-frontend my-project. it creates a project from reagent-frontend template. you can build your app with lein cljsbuild auto or build a production build with lein release.
- build time significantly drops, even with advanced optimizations, comparing to webpack.
- both component and app state management becomes a lot easier thanks to reagent atoms.
- not much of a big deal but hiccup templates make inline styling easier.
- you get figwheel!  
I find having the syntax, tools, and power of Clojure to be a much better experience than using vanilla js. There are so many things that just work, and having immutable data structures as the default is a plus, and a huge win. Further, I find that it makes things a lot easier to use with the backend, especially if it is also Clojure.
As far as working with the backend, I often am able to rename a clj file to cljs and it just works. I can also share the same exact code literally and insert the occasional reader conditional and cljc file. This is a huge win as well given both Clojure and Clojurescript encourage data-first approaches. Most of my code tends to be just maps, sets, lists, and vectors, with the occasional custom data structure. Sending this back and forth between client and server is infinitely easier and nicer than vanilla js. Adding things like EDN, transit, and libs that are built for dual use in Clojure and Clojurescript save a ton of time here as well.
Regarding tools, I find if you just use decent emacs plugins or an IDE like IntelliJ with the Cursive plugin, the syntax checking and dev experience is great. I tend to do a lot in the REPL which I feel is a productivity win for me over just working in chrome dev tools alone or some other js tools. Figwheel for example is another great one I use for doing hot code reloads/side-by-side changes.
For more specific and complex cases, I get even more benefit using reactjs from Clojurescript. There are multiple good frameworks in cljs that simplify the react experience and in some cases, even makes it run a bit faster (unless you replicated more or less the same immutable experience from js).
As for bad things, here's a few worth noting:
- Initial project setup can be a lot more of a pain, especially with lein. Boot can be an improvement but isn't as widely supported and doesn't always makes things easier. The larger point is there is a lot of ceremony getting new projects setup for non-trivial things. For trivial things, lein templates and various git repos make it quick.
- Some situations using vanilla js arrays can lead to better performance. It just depends because the opposite can be true. In both Clojure and Clojurescript I use transients where possible for a slight boost in some use-cases.
- Debugging can be a bit of a pain at times if you really have something deep. Since most things are data though, I don't really care that much as I normally solve problems using the REPL and/or dumping app state. In reagent and other frameworks, you tend to have a single atom i.e. source of truth which makes it easier than most typical approaches in js.
- Every once in awhile I hit something weird in Google Closure or a weird bug with Clojurescript itself. These tend to get fixed though and it's not hard to reach the actual devs.
- Clojurescript tends to make me hate using non-Clojurescript libraries. Interfacing is not difficult, rather the quality bar and extra dependencies that many npm projects pull in just make me insane. It's more of a personal and elitist thing that happens to a lot of people I know who use Cljs, but not really a problem, just pointing it out.