Technical writing is boring. But having an artsy trendy programming guide as part of a set of introductory materials is a way to "take a break" mentally without having to go off-topic.
Monads are not as hard as you think - it honestly helps if you stop thinking of them as a completely new concept with a scary name. I'm sure it wouldn't do people learning functional programming any favors to refer to the fold operator as a catamorphism all the time. (The syntax is also pretty funky, at first, with >>= and whatnot.)
I found it most helpful to think of monads as being similar to the pipe operator in Unix, but one that has a hook function it calls as it passes results along.
Also, the IO monad is probably the worst to start with; it's one of the most complicated. The Maybe monad is much simpler -- Think of a function that takes a function, f, and a second function, next_f. It calls f and grabs the result: if it's an error, then don't bother calling next_f, just return the error; otherwise, call next_f with the result as its argument. You can chain a bunch of Maybes together, and if any of them return an error, the whole chain immediately passes the error to the end. It's like how || (or) short-circuits in other languages, but much more general.
A similar Countdown monad could start with a time and a list of functions to call, then call them in succession, passing along the results, but immediately aborting and returning an error if the chain has exceeded the specified time to run.
The monad is the chaining construct, but you define what it does with the results it passes along.
Because of Haskell's type classes, it's able to recognize that any construct that supports that kind of chaining behavior (among other things) is an instance of the same general construct, and is therefore able to work with them in a common way. That's surprisingly useful, much like when an object's class is a Class object that supports various interfaces for interacting with the OO system itself (A "meta-object protocol").
Haskell makes a big deal of monads because it needs them to do some things in a functionally pure manner, of course. Still, they shouldn't be considered some completely alien by-PhDs-for-PhDs concept. (I remember Simon Peyton-Jones saying he wishes he'd instead named monads "warm fuzzy things"... :) )
This is, arguably, the biggest reason to use Monads in the first place, the typeclass thing.
You don't even need Monads to have completely functional IO code. Clean's uniqueness types are another method, but you can actually do it with just plain types if you're dedicated.
From my skimming, I'm afraid the author is only picking up one of the three things that make The Poignant Guide, well, poignant.
1) Witty, offbeat humor (w/ +1 for cartoons)
2) Interesting examples tackled
3) Restructuring the lesson to work for people who have learning styles unappreciated by typical tutorials.
I'm seeing routine examples like summing recursively/with foldr and implementing linked lists all within an outline not so different from any other Haskell tutorial.
Of course, the real acid test is seeing what zany metaphor the author thinks up to describe monads with.
