I feel it's more a case of functional programming trying to target the wrong segment - albeit out of necessity.
There's two kinds of programs being made. First most common one is the kind you're talking about here: grunt work. It's not about the code, but more about having the code do a straight forward task with very flexible constraints. A web app that talks to a database and does a few simple transformations -- like forum software or a todo app.
The second type is the interesting one: actual difficult code that does something unique and difficult and can take years to write by very experienced developers. Usually the difficult part here is coming up with the correct algorithm and then applying it, often with performance considerations being extremely important as the code is doing a lot of work. An impressive new MMORPG game, a new rendering technique, complex simulations, control code for rockets or advanced batteries.
The big program with functional programming is that it's never been positioned as a solution to the second type. Generally people trying the second type are told to use C, C++ or recently, Rust. Functional programming is marketed as making the first type "better" because trying to market it as being more efficient than C/C++ has not worked as people rely on micro benchmarks for these decisions. But this falls apart with the argument you gave: for the first type, it's better to just hire more junior programmers as there's nothing really difficult involved. And using a functional language makes it extremely difficult to hire junior programmers, because functional languages are aimed at advanced programmers.
It's a massive product-market fit problem.