That's cool - we've used bidi for years on lots of projects and have always just built our links w/ string concatenation. Formalizing this more makes a lot of sense.
With SPAs we've put a decent amount of thought into the tradeoffs between URI length, and putting enough context in each link to reconstitute the app state from a combination of local-storage, data requested from the server, and pure frontend db state (navigation location, parameters, etc...)
Perhaps there's some connection here as well with datafy/nav, there are increasingly spaces where REST-ish graphs of data are arising and capitalizing on the formalism in reference/navigation with something like this seems like a good idea too.
The answer to the rhetorical titular question is 'some probably have, but not in general, no'.
The business logic goes in a .cljc file, and the frontend and backend are both written in Clojure, so it doesn't matter if the components are rendered into html on the server or on the client.
The win isn't avoiding js so that you can have more html, the win is clojure's (edn) data-oriented approach to frontend (hiccup) that lets us use the most powerful language in sight (clojure) to never have to write any js or html. (:
In my experience, it's surprisingly helpful to have knowledge of Java libraries and an understanding of Java classes, objects, etc... when working in the JVM with Clojure. Otherwise, one would need to spend time understanding streams and readers and writers and the typical mutable java collections, etc... It's also helpful to be able to find a free Java library and to know how to interoperate w/ it and wrap it up behind a nicer functional interface (knowing the connection from Clojure to the host VM).
In terms of 'useful for employers', I don't think there's anything more useful than having written and deployed Clojure programs that solve real problems. I'd say write a Clojure program, see if it's fun for you, and then go from there.
Of course, still small relative to other language communities (esp. JS and Python), but for web backends it's wonderful. http-kit is a solid server with a nice simple design and passable performance and features. next-jdbc is similar for relational database connections. In general, the JVM is very powerful and getting better all time, OpenJDK is an amazing project that answered many looming questions about Oracle's licensing plans.
I'd say in the last 7 years in particular there's been a push toward more professional use of Clojure, with things like https://www.whyclojure.com/ popping up, and the prominent use at NuBank driving interest from consumer finance and finance-adjacent corporates.
My personal interest is in Clojure's use in data science, which is related to web backends in that it can be used to tell a more complete full-stack story that can include analytics, prediction, etc... We're finding in our work that a functional approach to data science saves a lot of headaches, and Clojure's inherent orientation toward data eases a lot of pain we've encountered doing data science in non-functional ways in the past.
Could probably try to pinpoint where Clojure is on the Gartner hype cycle today, as I certainly see less activity and frothy hobbyist fervor here and in other places; but that's a bit of a futile exercise. If you peel one layer off, you'll probably find that some of us just grew up and now are just happily and productively making money and things and helping people, with the immense leverage we always knew Clojure had.
For one-dimensional problems (Like forward generation of word sequences) there are definite comparisons to be made.
In my experience (having used both nets and markov processes in computational creativity), nets hold more promise for higher-dimensional problems (e.g., 2d image generation).
I'm all for having more toys the toybox though, so I hope work continues on both/all fronts.
