I disagree. If everything is evaluated eagerly, intuition usually works. Failing that, tools like logging and debugging and profiling will usually bridge the gap. A non-strict language like Haskell makes it much more difficult to predict run-time performance characteristics, unless you introduce overrides all over the place to force everything to be strict anyway.

exactly my experience. I personally find lazy evaluation a neat idea in principle. In practice, it introduces problems I never had in - let's say - java. One primary problem is that errors become delocalized in the code base. In a strictly evaluating language, the stack trace gives me a pretty accurate idea when and where an error is occuring. In lazy languages, it can happen when you don't expect it.

There is some irony in the fact, that a well-received tool for working with haskell code bases (intero) has bugs (space leaks iirc) that just cannot be tracked down properly.