Also, can't resist nitpicking about tail call optimization: clang/llvm and gcc implement it in a non-gc language (C), but meanwhile some FP language implementations lack it, at least Clojure does. So while there's more demand for that feature in the FP world and some FP languages like Scheme require implementations to perform this optimization, it's conceptually somewhat orthogonal to FP or GC.
Those concepts helped me avoid a lot of headaches without knowing that those are concepts of FP. Then there was a day where I just realized, "Oh, this is FP"
I guess people need to be educated, or experience themselves, the concepts, before hearing the word "FP" which mean less to them.
The examples provided in the internet needs to be more ambituous than mere chains of functions. They need to be "remaking rsync with minimum IFs" or "large scale React App without a single getDerivedState"
2. Being a relatively new paradigm, less people understand where, when, how, and why FP fits. There is a lack of effective education over FP.
3. Having some radical jargons (e.g. HOF, recursion > looping) , FP brings fear of change. Especially, recursion > looping can only be applied to languages with gc, preferably those with tail call optimization.
4. FP's more universal virtues (immutability, pure functions, type system, no side effect) are not advertised enough compared to other virtues (recursion, hof).