First of all - because the compiler have to do much more. If you want to create imperative compiler you can nearly do 1-1 transformation to assembler and the code produced will have acceptable speed (sure - there could be much to do but it is 'basicly' 1-1 compilation + optimalisation). Functional compilers HAVE TO handle well heavy inlineing, tail-call optimalisation etc. Therefore implementation of functional languages were much slower then C/C++/... in past (however they gain much speed each iteration as compilers are getting better).

Secondly - programmers are so used to state that they cannot 'accept' "there is no spoo... state" approach. Sure - the lack of state is not useful in each condition but the lack of (global) state does not mean lack of local state.

Thirdly - functional programming have no nice story behind it. The OOP have nice story as the objects maps to nouns and how intuitive it is. Afterwards you know that it is not so simple because you cannot create a class Manager as subclass of Employee as Employee may get promote to Manager and you have to play around decorators. The functional programs have story in mathematics which is IMHO more useful but less marketable.

As internally from the computer perspective - there is no difference between parallel and concurrent computing many programmers do not see a difference and many languages have the same primitives to handle both. Thank to lack of local state and lightweight threads in functional programming languages the parallelisation of algorithm is much easier. However concurrent programming is not made automatically easier as concurrency is about global state.

Finally - there is a lot of older programs written in inperative style. Even porting from imperative language to imperative language is much simpler then to functional one.

As far as I know investment banks start embracing the functional programs internally so they DO come into XXI c. (in very important although hidden area) - so they do gain momentum.

PS. While I believe that functional programs are "better" in meaning they hide the complexity better then other approaches it does not mean that there are no areas such as scripts that are inherently imperative.

First of all - because the compiler has to do much more. If you want to create an imperative compiler, you can nearly do 1-1 transformation to assembler and the code produced will have acceptable speed (sure, there could be much to do, but it is 'basically' 1-1 compilation + optimisation). Functional compilers HAVE TO handle well heavy inlining, tail-call optimisation, etc. Therefore, implementation of functional languages were much slower than C/C++/... in the past (however, they gain much speed each iteration as compilers are getting better).

Secondly - programmers are so used to state that they cannot 'accept' "there is no spoo... state" approach. Sure, the lack of state is not useful in each condition, but the lack of (global) state does not mean lack of local state.

Thirdly - functional programming has no nice story behind it. The OOP has nice story as the objects map to nouns and how intuitive it is. Afterwards, you know that it is not so simple because you cannot create a class Manager as subclass of Employee as Employee may get promoted to Manager and you have to play around decorators. The functional programs have story in mathematics which is IMHO more useful but less marketable.

As internally from the computer perspective - there is no difference between parallel and concurrent computing. Many programmers do not see a difference and many languages have the same primitives to handle both. Thanks to lack of local state and lightweight threads in functional programming languages, the parallelisation of algorithm is much easier. However, concurrent programming is not made automatically easier as concurrency is about global state.

Finally - there is a lot of older programs written in imperative style. Even porting from imperative language to imperative language is much simpler than to functional ones.

As far as I know, investment banks start embracing the functional programs internally so they DO come into XXI c. (in very important although hidden area) - so they do gain momentum.

PS. While I believe that functional programs are "better" in meaning, they hide the complexity better than other approaches, it does not mean that there are no areas such as scripts that are inherently imperative.