There is absolutely no point single stepping through code, setting up breakpoints, inspecting variables etc, when you could instead just insert an extra log statement to see what is going wrong.
If your logging is good, often solving a bug is just a case of looking in a production log and seeing where things went wrong.
The other fact is that the majority of bugs I've seen in my own code have been caused when under load, and it's not feasible to run a debugger on a production system.
I've tried debuggers a fair amount, and they end up being completely useless to me.
I assume that statement refers to the amount of noise in question?
Sure, print statements are my normal tool, but often I'm working on transforming one data structure into another (compiler-style) and I'm encountering an error "somewhere" down in the middle. After the first few megabytes of logging output get generated, you start to really lose the thread of what's going on.
It depends on what you're doing. If you're a CRUD programmer, yeah, I can see how they'd be useless; that's a good deal of my job too and I don't use them then. But when I'm actually doing something interesting and twisty I often need them, if only to set some conditional breakpoints somewhere so I can get into the middle of a complicated process instead of trying to reconstruct the state later.
Also they are great for learning libraries by stepping through them.
A debugger is just a tool and to dismiss a tool as being pointless for all people is ridiculous. Being familiar with all the tools at your disposal as a software developer is never a bad thing.
Debugging helps you work with code you don't understand. So, the longer you work with the same code the less useful it becomes. However, plenty of coders move from project to project patch up a few problems and then move on.
I'd say not having a debugger is more like programming on paper. When you have a problem, you might end up thinking about it a little more because you can't rely on that one other tool.
I think it's more like never being taught how to use a knife, and thus eating the steak with your bare-hands, as you've always done. Hands work fine, why learn something new? I have no formal training in programming and it never really occurred to me to use a debugger. I still don't entirely understand what they do for you that you can't do by adding print/trace statements. That said I mostly use scripting languages and don't need to read too much code written by other people...
They allow you to evaluate state and often see things you'd miss otherwise.
Plus they can do what prints can do, but even easier. I can use tracepoints to print anything at any point in code, including the callstack. The nice thing though is I can turn the tracepoints on and off while never pausing/breaking the code.
Additionally I can attach a debugger to a running process.
Plus with more modern features, like historical debugging), I can go back to predefined instances of time (like a past exception that was thrown) and examine the callstack then.
And the other thing you can do interactively is (a) change the value of variables, (b) change the code, and (c) change the instruction pointer. I regularly do (a) & (c) -- (b) less so. It's a huge time saver when you step over function foo() and realize, hey it didn't set ABC. So then just set the IP back to foo(), but this time step into it.
When I would consult I would often find and fix bugs in a day or two with oode that I'd only seen for the first time, while others had been looking for weeks in code they had helped build. I'd look at their debugging techniques and it was obivous that they were often just not at all efficient.