The benefit of Haskell for me is not that it allows "idiots" to write decent code, but that it allows very smart people to write decent code.
It's much harder (in my experience) for very smart people to write decent code in C, C++, Python etc than in Haskell, simply because so much of their smartness is consumed by having to constantly think about what code might break their program.
Absolutely, which is why the compiler should remove as much thinking burden from the programer as possible. Then he/she has more free brainpower to spend on additional important things.
Exactly the same rhetoric about those evil pointers and safety of static typing and compiler technology was that gave rise to Java.
Haskell, it seems, while using the same slogans, plus FP and lazyness buzzwords, is really doing the job when you follow its conventions.
Actually, that part which re-implements standard FP techniques with very clever and concise, based on familiar conventions (currying, laziness) syntax, along with ability to write "curried type signatures" is remarkable. It feels much better than SML.
It is definitely the language worth of learning after Scheme/CL.)
This is an such a bone dry straw man it's liable to spontaneously combust in the summer sun.
The fact that corporate overlords selling Java made certain overhyped promises does not have any bearing whatsoever on the merits of Haskell.
Let's break it down: Java fixed memory management at a significant performance cost, but they didn't solve null references, and in practice it was a big enough of an advancement to actually get a foothold against C++.
Haskell on the other hand actually solves null references as well, so the bugspace that it actually eliminates is easily an order of magnitude bigger than Java's, and it does so without being particularly slow or verbose.
Now as to the rest of your argument, of course it's true that FP principles can be applied anywhere, and given the correct discipline you can achieve much of the same benefits through careful architecture and coding practices. However what you're dismissing is the value of the compiler guarantee, and that should not be minimized. Of course we can look at any code sample and reason about how it should be structured to minimize side effects. But the problems with mutability and null references are endemic to large systems, not isolated features. Where Haskell's guarantees start to shine is when your code base goes over 100kloc and no one person understands the whole thing anymore and the preconditions informing the design no longer apply and things have been hacked from a dozen different perspectives. In this case those guarantees have non-trivial value.
It's much harder (in my experience) for very smart people to write decent code in C, C++, Python etc than in Haskell, simply because so much of their smartness is consumed by having to constantly think about what code might break their program.