The real problem is state.
Functional languages don't have global state. Most industrial problems require state at the large scale (how do you represent a ledger or a set of transaction) even if some functions at the small scale do not actually require it (processing a ledger).
But we are running code on Von-Neuman architecture machines which are inherently state-full. So we have not actually got rid of state, the functional languages just hide the complexity of state from the developer. This means that language/compiler has to deal with state behind the scenes and managing it.
So though functional languages have no global state, their state information is passed as parameters and result.
So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.
Looking at it from Hardware Side
The OS has helped a lot in the last couple of years in visualizing address space so applications do not officially need to worry about it. But applications that do not worry about fall into the trap of thrashing the hardware when memory pressure becomes intense (thrashing hardware will slow your processes to a crawl).
As the programmer has not direct control over state in the functional language they must rely on the compiler to handle this and I have not seen functional languages that handle this well.
On the converse side of the coin the state-full programmer has direct control over state and can thus compensate for low memory conditions. Though I have not seen many programmers that are actually smart enough to do so.
Looking at from the industry side:
Industry has a lot of inefficient state-full programers.
But it is easy to measure improvements in these programs over time. You throw a team of developers at the problem they can improve the code by improving how the program handles state.
For functional programs the improvements are more difficult to measure as you need to improve the tools that will improve the programs (we are just looking at how applications handle underlying state efficiently here, not the overall improvement of the program).
So for industry I think it comes down to the ability to measure improvements in the code.
From a hiring perspective
There are a lot of stat-full programmers available for hire. Functional programers are hard to find. So your basic supply and demand model would kick in if industry swapped to functional style programing and that is not something they want to happen (programmers are expensive enough as it is).