What's good about print statements is that they don't require me to do anything more than once. When you run code in a debugger, there is a lot of manual interaction involved. continue, break, see where you are, think about that, poke around, repeat. With print statements, you run your test, analyze the output, and make the changes. It's all automated except for the analysis step, which is all the human should be doing.
If you need breakpoints, watchpoints, and a GUI to click around in, your code is too complicated and unmaintainable, which is probably why you need a debugger in the first place.
Manual interaction? Sorry, but I'm still very skeptical. Pausing in a debugger does not require materially more "manual interaction" than endlessly running your program to spit out some printed statements--it just front-loads the manual interaction so you're doing it sooner and, if you're doing it right, doing less of it. A debugger allows live autopsy, which is far more valuable than this silly print-statement thing--when your print statement does not return as expected, you are not much better off with your print statements than just seeing the broken output of the program.
Couple live autopsy with live edit-and-continue and you've got a recipe for a considerably more effective way of debugging code.
And "your code is too complicated and unmaintainable if you need a debugger" is preposterous on its face if you've ever...oh, I don't know...written a driver? Or any other remotely complex (you're conflating complicated and complex) task with a significant number of interlocking parts? (Hell, one could just as easily say that your code is too complicated and unmaintainable if you're barfing print statements all over the place.)
You "step over" instead of "step into". Now what? You have to start over.
With test cases and print statements, starting over is free. If you need more information, edit the code to give it to you and re-run.
Getting a debugged program back to the desired state is, in my experience, difficult even with an automatic test. Not only does the program state have to be right, but so does the debugger state. Without the debugger, you have half the state to bother with.
I like logging for this, but the concept is basically the same. Being able to switch on debug logging on a running system has saved the day more than once for me.
Thing is, logging and debugging are not in opposition. My current web app is...well, verbose is probably putting it mildly. But when developing locally, if something goes sideways I just say "hey, stop here" and I can introspect the entire kit and kaboodle without even having to re-bounce the debug server (and certainly without stopping it to bung in a bunch of print statements).
I agree somewhat (although I do feel that debuggers are useful) in that IDEs can influence the design of your program by encouraging a debug first development style similar to "programming by coincidence"
If you need breakpoints, watchpoints, and a GUI to click around in, your code is too complicated and unmaintainable, which is probably why you need a debugger in the first place.