When I think about what functional programming might bring to my projects at work I'm always led down the same path of thought:
To get the full advantages of functional programming you need laziness. Yes, there are strict functional languages, but the real benefits of functional programming don't shine as well in strict code. For example, in Haskell it's easy to create a sequence of lazy operations on a list and concatenate them and apply them to a list. Eg. op1 $ op2 $ op3 $ op4 $ someList. I know that it's not going to build the entire list and internally I'm just going to get a nice loop that walks through the elements one at a time. This allows you to write really modular code. The interface between two modules can involve handing over potentially vast data structures, and yet you don't have to have the structure resident.
But when you have laziness, it becomes hard to reason about memory usage. Changing the Haskell compiler flags frequently changes the amount of memory used by an algorithm from O(N) to O(1), except sometimes it doesn't. This isn't really acceptable when you have applications that need to make maximum use of all available memory, and it's not great even for applications that don't need all memory.
