For starters I shan't cop-out and claim Haskell is primarily a research vehicle. So it's succeeding in some sense. We'll live.
So here's my take: Most people yield defeat at monads. And then the few that survive find that they have to face iteratees and co. Rage and tears don't even begin to express it.
You're right, there's no guidance about iteratees. Material on this issue, not unlike monads; not unlike space complexity tradeoffs in lazy evaluation; hell, not unlike almost everything about haskell, is all over the place. And that sucks balls.
Do I have a solution? I'd counter, isn't this the price to pay for being on the bleeding edge? And I'd contribute this: there used to be a time when people felt a greater affordance to try anything half-baked, fiddle with it here and there, and BBS to others about it. Over the years there's this expectation creep that everything has to be perfect like an immaculate birth. Perfect! With guidance included!
I want to say that this is due to the decline of leisure time. But that can't be the whole story.
Meaning, people will pay a lot and care a lot about curing some particular disease, but preventing it... they might pay something for it, but it's probably not really on their radar.
Haskell, with all the fancy CS stuff, is selling prevention, in some sense. "We promise that your code will somehow be better"... well ok, but that doesn't really sell me. I'm being told to eat my vegetables rather than being shown a tasty steak. Compare and contrast with Rails when it came out, which showed you how you could write code that was 1) more organized than PHP, but 2) not as bureaucratic as Java. Cool stuff!
Reality is not black and white, but perhaps there's a grain of truth in there? Perhaps Haskell people could do a better job of showing how the CS stuff helps with real problems? I can't really say as it's simply not on my radar all that much, so they could well be screaming about it from the rooftops and I wouldn't have heard too much.