I'll try to give a short answer, but suppose for the purpose of this discussion that Haskell and Erlang both address the project's initial code concerns equally well. Large, dependable projects, with a long projected usage, have some general requirements that are well-known and tend to be the same for most of them. They include ease of training, ease of hiring, ease of reading and modifying other people's code, ease of upgrade, ease of debugging, ease of profiling, ease of monitoring running software and more. In short, ease of maintenance. Languages built by the industry and designed and used by industry tend to put a lot of emphasis on this, while languages built in academia tend to care more about language expressiveness, code reuse (through graceful abstractions) etc.. Those are important things that matter to the industry too, but not nearly as much as the ones I mentioned. Because language maintainers have limited resources, often one set of requirements comes at the expense of the other. Sometimes the concerns in the latter group can even directly conflict with those in the first; for example, powerful abstractions can become too clever, hard to learn, and hard to understand by reading the code (I think this might be the case with Haskell, but not necessarily so for any hypothetical "academic" language).

Thanks for that!