This is only true for tiny toy benchmarks, not for real applications. For real applications you're going to have bottle necks in small parts of the code. So what if that 5-20% of the code has to be written using specialized techniques to get speed, when you get several times more productivity/correctness/maintainability in the 80-95% of the code which is not the bottle neck?

If you're involved in a game where everyone tries to show off how their programming language deals with the bottle necks then obviously you'd use these "ugly" techniques to optimize things. It may be that it's more convenient to write this low level code in C (though I wouldn't say it's "much" more convenient, slightly more for some cases, less for others), but the price you pay is that you have to use this low level style for *everything*. Most of the inconvenience, IMO, is due to syntax not semantics (specifically having to do "<-" on separate lines in order to read mutable memory rather than being able to extract the value at the usage site - though I do believe some syntactic sugar was on the way for that?)

So I think you're wrong to criticize people for showing that Haskell can be fast. Yes it takes effort (though you can increasingly avoid most of it by using libraries like ByteString), but nobody is saying that it doesn't. You're arguing against a straw man. The point is that you *can* get good performance in Haskell for the parts of your programs which is a bottle neck. The shootout only tests these parts, which is why the Haskell code in those submissions is sometimes a bit obscure (though not nearly to the extent you make out). But that's not how *real* applications look! In real applications that kind of code would be only a fraction of the total code base, most of it would be perfectly ordinary Haskell! (whereas in C everything would be, well C) 

Cheers,