[namelosw]

That depends on what problem or code base you are working with.

The debugger is the best answer when you are working with bad code, which you cannot reason about the code locally -- a random bug only happens on the production env, a mutable monolith, or a complex system integrating with 3rd party services. Because debugging is to know what happens in the first step, then build a theory to reason about everything. Sometimes, fixing the plane in middle-air requires you need to know what happened to the specific plain, instead of building a theory to make a plane having the exact problem without looking at the plane itself. Like in control theory if there are too many possible states, it's not cost efficient to reason about the state from behavior -- wherein software you can cheat and inspect the state directly.

However, I agree with the author that in the ideal scenario there's almost no need to use the debugger. Like in SICP, in the first few chapters the mental model is about the substitution model -- it's not how a computer really works, but it's easier to reason about, you don't have to in specific step with the specific environment to reproduce the problem (that's where debugger really helps). The code is written is a matter which is more coupled with the environment (which reflects the environment model in the following chapters), the more one needs to use the debugger to work with that code. And that's why the virtue of functional programming and the referential transparency are praiseworthy.