Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.
This is especially true in multithreaded code. I do a lot of Qt programming, and everything tends to be executed in an auxiliary thread.
I will say that I like step debuggers that come along with a REPL. This is probably the one and only thing I like about Matlab.
Lastly, I program in Haskell for fun (enough at least to write a small unit conversion library [1]). Because of laziness, I find the step debugger impossible to use. I definitely rely on print statements in Haskell.
At home I develop with C# and use the debugger all the time. However, I'm a PHP dev at work and we can't connect to our dev server with debuggers. We have all sorts of various tools we built for getting around it, like dumping objects to email and so forth. Although I kinda miss a step debugger at work I've got enough tools to deal with it, even if it's a bit slower sometimes. In other cases it's kinda freeing in a strange way.
Unit tests verify if the programmer's understanding of the code matches reality.
That's all. Not saying it's useless, but a) it's at best a start of proper testing, b) insisting on coverage is beyond useless.
What is needed is a test if the programmer's understanding of the problem is up to par. Since that's impossible, let's go with the programmer's understanding of the whole program : system and loadtests.
Unit tests, while useful for TDD for "fiddly" code, are useless to guarantee correctness of an application. System tests are better. Proper type system abstractions are best.
So your code never has bugs?
Any production piece of software is going to need debugged at some point. Sure, a step-through debugger like the one in VS isn't the only way to debug, but it sure as hell is one of the more intuitive ways.
Being able to expand objects and see their state etc. is extremely powerful and shouldn't be shrugged off as a nice-to-have.