Good luck starting a security company with the slogan "We provide 90% security!"
I don't know what you're talking about. If anything, that would be "90% fewer security vulnerabilities", which sounds like perfectly good marketing.
I do use Haskell myself for certain things, and I can tell you it's no problem creating insecure applications in Haskell.
I never said Haskell was the perfect language, just that it provides good examples of achieving the needed safety properties, in that it can be extended to verify many properties that may be of interest. I didn't define "safe" in my original post, as the requried "safety" properties are domain-specific. Memory safety is the minimum needed, which would automatically handle one of the most common vulnerabilities in single programs (buffer overflows). A language that can be used to specify and check the required properties is a "safe" language for a given domain. Many languages fit most problems, few languages may be safe for all problems (although possibly undesirable for other reasons).
If all we had were Haskell's DoS vulnerabilities, we would be in a much better place.
Most exploits are due to human errors they could have done in any language
Not a chance. Here's a list of the top 25 exploits from 2011. From this list, numbers 3 and 20 would have been solved right away by using any memory safe language. Most memory safe languages also implement overflow checking, so that's 24 off too.
Languages featuring parametric polymorphism can tag unsafe values received as user inputs, so you can easily solve vulnerabilities 1, 2, 10, 14, 22, and 23 (all you really need is parametric polymorphism -- I've even done this in C#).
The crypto entries can be handled with session types that expect encrypted packets, not plaintext. Even the selection of appropriate crypto algorithm can be constrained by various parameters and checked at compile-time, ie. a Haskell type class constraint could specify a whitelist of unbroken crypto algorithms for unrestricted use, and those which are only good in restricted scenarios.
Design by contract can handle precondition violations, ie. #18, and such contracts can be statically checked these days in Haskell, C# and Ada.
A capability-secure language would handle the rest (mainly "porous defense" category remains). Few languages implement full capability security properties, and they remain vulnerable to the extent that they violate those principles.
The point is that the needed safety properties to address most common security vulnerabilities have been known for decades. Capability security was invented in the 1960s, and memory safety has been available since the first Lisp. Unfortunately, many programmers aren't interested in safety properties because they're focused too much on raw speed, but don't want to spend the verification effort to use that speed safely (Frama-C or Ada), or they want to avoid all verification effort period (dynamically typed languages).