Lack of training and lack of awareness. Here at work (in France), probably less than 3% of programmers ever used Haskell or ML. Less than 10% knows they even exist. And no-one would be willing to train a team so these languages can be used in a new project.
Now, financial software may get away with those because they don't really have a choice: they are a narrow field, with a critical need for correctness.
Conversely, you could say that most projects get away with ignorance. They use sub-optimal languages, for the very short term benefit of not training people.
I don't think Haskell training per se would ever work.
Haskell is beautiful because smart people find it to be a really good way to express their problems and solutions. Haskell is the way their thinking comes out. So if you're in that 3% you probably know and possibly even use Haskell already because you have that sort of train of thought. If you're in the remaining 97%, you could only do much less or barely nothing at all until you had had a long series of "aha!"s, not often even related to Haskell itself.
Instead of language training, effectively a mindset-changing smartness training is what would have to come first.
For most people Haskell is the first introduction to some concepts (lazy eval, functional purity, etc.) that makes Haskell compelling in the first place. So as Haskell looks so foreign and they do not see the benefits they will reap, they do not even start. When learning Haskell you get rewarded as you progress but you have to work a little at the beginning (same with Common Lisp, at least for me.)
At $WORK I used to show some cool stuff in another language and tell my coworkers it is built-in in Haskell (the concurrency stuff is what interested them.) I hope some of them will have a look at it in their spare time.
Another possible issue, depending on your approach, can be how to integrate with external systems. I have seen teams trying to deploy a Haskell based common library to a heterogenous production environment and it wasn't pretty.
The core Haskell module itself solved a specific problem beautifully, but it all got very messy outside the confines of the pure and pretty functional world.
Also, financial companies have a lot of money to attract top talent. Your average company probably can't easily find people who would get up to speed quickly with Haskell, whereas they'll surely be able to get people who do Java or PHP, and these days, probably also find Python and Ruby developers without too much trouble too.
I'm shocked, shocked to hear there's such little ML going on in France. After discovering OCaml and its progenitor INRIA, I've always just assumed that MLs and functional programming was more of a European thing, especially since they're more oriented toward proofs and program correctness, which I also thought was more a characteristic of European CS and software engineering. But no?
OCaml is still quite academic, Caml-light (Caml without object and with some difference) is used to teach CS in some Math undergrad and it is use by academic researcher who don't want to go back to C. That's said there is not so much Engineering/Commercial use of it. (Some blame INRIA for not pushing it, supporting it enough, especially the lack of extended library and threading trouble).
There are pockets here and there, like INRIA and the Scala people around Odersky in Lausanne, Switzerland. But it's not something on a larger scale. I think Erlang is somewhat prominent in some places, too.
Especially the Lisp community seems to be almost completely American to me (in Europe), with Racket in Boston, SBCL from CMU, and Clojure, too. What's going on in Lisp development in Europe?
2 workplaces plus a good deal of acquaintances, in fact. In my niche (custom technical or scientific software, mostly for the government), I'm 99% confident that ML makes less than 0.1% of currently written code. 80% of my colleagues even never heard of ML.
I've always thought it was really weird how little OCaml was used in France, the French as a people tend to prefer do to things "the French way" (as opposed to the Anglo-Saxon way).
Now, financial software may get away with those because they don't really have a choice: they are a narrow field, with a critical need for correctness.
Conversely, you could say that most projects get away with ignorance. They use sub-optimal languages, for the very short term benefit of not training people.