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.