The hardest thing about functional programming is using it. Most of us have been using imperative programming since - well, forever - and FP might be really a hard thing to wrap your head around if you are used to imperative programming.
All imperative languages basically work the same way. To learn a new programming language it's usually a matter of learning the syntax and its built-in libraries. Given a problem, you'll probably already have a way of approaching it, it's just a matter of working out the syntax and minor kinks.
This is not the case with FP. This is nothing like the shift to OOP. Good programmers who didn't know OOP were likely using many OOP concepts already. FP on the other hand is a whole new way to program. Trying to implement relatively simple algorithms requires a new approach. Statelessness can be a bit of b@#%!.
However, multithreaded processors are becoming practically ubiquitous, and thread safety is still a very hard thing to "get it right." FP can gain some ground here with its statelessness, which allows you to be more carefree about thread safety and concurrency.
In short, I'd say the first line of resistance against FP is its difficulty for most programmers. Then, enterprises are usually wary of new and/or unproven technologies. With languages like Java, C and C++ firmly entrenched in the enterprise world, it takes a lot of time for anything new (or perceived to be new) to gain market.
Also, large existing codebases are not likely to be touched. You'd be surprised at how many people still use languages like FORTRAN and COBOL nowadays. Some times the decisions like to use a new language lies with managers that don't have a technical background. Good luck convincing them they should switch to a language most people aren't comfortable with (ie: will likely cost them).
