Once you get to a complex enough system, sometimes a debugger just isn't enough.
E.g. I have a multi-threaded and multi-process robot control system - I can't put breakpoints in the controller to debug why the robot misbehaves, because then the control loop timing is broken and the robot faults. Instead, you have to put the time into effective logging tools, so that you can capture the behavior of the running system and translate that into a simpler and smaller example that can be examined offline. Maybe those you run under a debugger, but you probably can express what values you want to examine and when more cleanly in code than in the debugger, with the significant advantage that it's easier to communicate "run this code and look at the output at step n" than "run this code with these breakpoints and these debugger scripts".
My view at this point is that the conditions I would normally examine in a debugger with breakpoint and stepping are usually so rare (e.g. a few in potentially thousands/millions of iterations) that I need to write logic to express what checks and where I want to make them, and I would rather write that logic in the context of the program itself than do so in the debugger.
Ofcourse there are edge cases that don't work with a debugger. I have been there too. Timing sensitive applications like controlling the fat-TV live on scanline/pixel level can't be debugged. Physical objects that move over a certain speed can't be live debugged because of physics. This is still edge cases.
Arguably, once you are working on a sufficiently complex and mature system with good-enough tooling and tests and development practices, these edge cases can come to dominate. I don't spend time debugging simple things on their own, because the simple things on their own are generally well tested, so the failures that do happen emerge from their combination and integration into complex systems.
That said, I do spend a fair bit of time using a debugger as my first-line response to an issue - but overwhelmingly it's to examine a crashdump of the failure rather than investigate a live process.
E.g. I have a multi-threaded and multi-process robot control system - I can't put breakpoints in the controller to debug why the robot misbehaves, because then the control loop timing is broken and the robot faults. Instead, you have to put the time into effective logging tools, so that you can capture the behavior of the running system and translate that into a simpler and smaller example that can be examined offline. Maybe those you run under a debugger, but you probably can express what values you want to examine and when more cleanly in code than in the debugger, with the significant advantage that it's easier to communicate "run this code and look at the output at step n" than "run this code with these breakpoints and these debugger scripts".
My view at this point is that the conditions I would normally examine in a debugger with breakpoint and stepping are usually so rare (e.g. a few in potentially thousands/millions of iterations) that I need to write logic to express what checks and where I want to make them, and I would rather write that logic in the context of the program itself than do so in the debugger.