This is like trying to debug leaks in C with printf. It is just not done. Where's Haskell's valgrind-like tool?
http://book.realworldhaskell.org/read/profiling-and-optimiza...
The question then becomes, why couldn't the author use them to help pinpoint the source of his issues?
When reasoning about Haskell code, due to non-strict evaluation you get a kind of "spooky action at a distance." If your program flow is something like "let result = C(B(A())", where A, B, and C are functions, an expression deep within function A may not be evaluated until you are in the middle of evaluating C -- or possibly never evaluated at all, if the value of that A expression isn't required to compute the return value of C. To reason about the runtime behaviour inside A, you may have to reason about the expressions that consume the return value of A. This can feel like chaos to someone who works with imperative languages, and who is used to nice things like explicit, linear stack traces: in Haskell, evaluation is driven by need, not by imperative instruction, and so the execution flow can look inside-out at times. That's not to say that better tooling isn't possible -- but it is a challenging problem.
I don't know about spooky, it makes more sense if you think in terms of "call by need".