You don't need emacs for good parenthesis control. The same tools emacs uses for this are available in about a dozen editors at least. Vim, Atom, Cursive/IntelliJ, Eclipse, Sublime Text, it's pretty common in most good editors.

Understanding programs with recusion requires actually programming with recusion that many devs just aren't exposed to. It's just not the dominant paradigm

Explicit recursion is rarely used in FP, and it's often a code smell. It's almost always better to use higher order functions instead. The advantage is that you can implement a particular transformation once, check for edge cases, and reuse it from there on. You also end up with declarative code that talks about what it's doing without distracting your with implementation details.

Clojure has a rich set of functions for manipulating data such as map, filter, reduce, and so on. There are also libraries such as Specter https://github.com/nathanmarz/specter that allow you to declaratively transform complex data. I highly recommend watching this https://youtu.be/rh5J4vacG98 short video to see how it works.

You misinterpret my comment thinking it is a statement about myself, when it is a statement about the wider programming community.

My point is that you don't really program with recursion in Clojure, so it's not an actual problem for people using the language.

My point is that there is a learning curve no matter which way you slice it, as one must also learn to use higher-order functions effectively (I do not believe mainstream devs know this innately) and this is an obstacle for newcomers.

Pretty much all mainstream languages use higher order functions nowadays, it really shouldn't be a foreign concept at this point.

The basics of HOF are not foreign concepts at this point (e.g. map, filter). But FP amplifies the degree and nature in which they are used.

for example learning to use folds or transducers. Learning to avoid mutation etc

Why is learning a few FP concepts considered more taxing than the all the cruft which accompanies OOP? My experience is that FP concepts and idioms are a breath of fresh air compared with OOP design patterns.

It is not 'more taxing'. It is less familiar and implies an effort to learn for an existing dev. (I am talking about existing devs, not those learning their first language). The issue for those folks is not absolute difficulty but motivation.

All I can say here is that my team has been using Clojure for over 7 years now, and hiring devs hasn't been a problem. At this point, my view is that if somebody has problems learning these concepts, I probably wouldn't want to hire them to work with any language.

I have no doubt you've had great success with clojure.

However I question generalizing from 'this was not an issue for my team at my company' to 'this should not be a concern for any company under any given constraints'.

I don't doubt most devs wouldn't have problems learning these concepts. It's whether business have capacity to allow those devs to onboard in such a fashion, knowing that different business are subject to different constraints.

There are many companies using Clojure large and small, nobody actually using the language has problems hiring people for it. This is not a theoretical debate, there's no evidence to support the notion that Clojure is hard to hire for.

In practice, the language is a small part of what a new hire has to learn. Each company has different processes, tools, workflows, frameworks, and so on. A language is only a small part of that.

While there are obviously companies where Clojure wouldn't be a good fit, the reasons wouldn't be that it's hard to train new people to work with it.

You don't even have to use Emacs nowadays. Atom has lisp-paredit and parinfer package, VS Code has paredit, Cursive has a structural mode, and so on.