RWH’s “Here’s how you get the job done” style exposition did a reasonably good job of making me feel comfortable turning on profiling of my Haskell programs, but didn’t give me much sense at all of why the particular examples they chose were particularly representative of space leaks. I went on to do some amount of performance tuning of some data structures http://blog.ezyang.com/2010/03/the-case-of-the-hash-array-ma... ... but I still managed to miss some really obvious performance bugs that Tibell caught later when he revamped my benchmarks http://blog.johantibell.com/2011/03/video-of-my-hashing-base... . I just didn’t know where to look! All I had were a bunch of patterns: "watch out for lazy folds", "using bang patterns can be a good thing", without any particular mental model of how to deduce these things from just looking at code.
To be honest about the Wikibooks article... I found it hard to read. (Which is terrible, since it's a wiki, and if I don't like it, I should improve the article...) Exactly why is hard to pinpoint. It might be statements like "Haskell values are highly layered"; it might be the fact that none of the examples are in motion (they don’t show before-and-after; the actual operation of the program!); it might be that in many respects, its coverage is incomplete.
Obviously, this series isn’t going to be the be-all, end-all reference for laziness. While it would be extremely gratifying to see other people take up the ghosts and presents metaphor, I’ll be content if people walk away with a sort of visceral feeling about all the churning that goes on under the hood when they write a functional program, so that it’s not surprising when a trace statement shows up much later than you expect it and so that it’s not a matter of trial-and-error inserting bang-fields and seqs.