Looks like one of those topics that are highly sensitive and triggers very opinionated reactions bordering flame wars. (Apparently, programming is an ideal target for those topics! I've rarely seen "general" programming topics not ending with fights. Let's be happy though when there's no personal attacks or name calling.
)
This is also a frequently discussed topic, so we're all likely to repeat ourselves a good deal.
I personally agree with Siwastaja and Bruce here. I haven't used an interactive debugger on embedded devices for literally ages, and use one very infrequently for "desktop" programming (like maybe a couple times a... year.)
Debugging in general, and not just for software, is all about 1/ observation and 2/ being methodical. There are tons of ways you can "observe" the behavior of running code. The "right" one to use all depends on the context. As to being methodical, interactive debugging rarely promotes it. But if or when a debugger is appropriate for observing a particular behavior that you can't otherwise pinpoint, sure, use one! I just tend to use those as a last resort rather than as first intention.
The (almost) only case in which I'll fire up a debugger like gdb is when the code is crashing. The debugger will locate the line where it happens which will save you time. Once it's located, you may or may not step through the code - depends on the context - but usually, just the backtrace and looking at variables/parameters is enough to proceed, and then you can quit the debugger and go from there.
Of course, some development methods make it less likely you'll run into intractable bugs requiring stepping frantically through code in a debbuger, such as testing relatively small parts of your code as you write it, and proceed incrementally, as Bruce suggested. It again can/has to be adapted to the particular project, your coding abilities and the complexity of the code. Unit testing at too fine a grain, or on trivial functions, is useless and silly: use common sense.
Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments. It's a tremendous help. Here again, use common sense though.
Tracing using some logging/printf/whatever is of course also useful and usually more productive than manually stepping through code.
While overly generalizing is rarely relevant, resorting to an interactive debugger instead of using one of the above methods (or others of your choice, by no means exhaustive) *can* be a sign that you favor "instant gratification", while using other methods often takes a bit more time upfront, but once done, that can (and usually is) a big time saver at the end of the day. Again not to generalize, but I would say that it is a bit akin to people who have a tendency to copy/paste code repeatedly to achieve a given task rather than pause for a moment and factor code so that the end result is much more maintainable, a lot less prone to errors and will save you a lot of time down the line. Yet some people, from my experience, tend to see this as a waste of time.
So, yeah. My 2 cents.