If you are debugging a program inserting printf or other debug prints in the code you are doing it wrong, for debugging you should use a debugger.
It's slow and inefficient, you add the debug print, then you need to recompile the program, maybe you need another debug print, recompile the program, and so on, and then you must remember to delete all the debug prints that you added! And let's hope that your debug print didn't add some strange side effect (they might have!).
With a modern debugger you could print everything you want, at every memory location, you could set watchpoints, isn't it better than printf ? Also where you printf on an embedded system...
Sometimes you just can't do that, without completely breaking everything while the program is halted in the debugger. Particularly real-time, multithreaded applications.
Not necessarily. It's about timescales and other environmental factors. Pausing in a debugger is measured in seconds. Your network-using application won't notice extra half ms for a print statement, but might change its behaviour if you pause it for 5 seconds, as requests will timeout. A video game running in fullscreen won't mind printing to console/file in the background, but may not handle well being interrupted in the middle of rendering and having you switch focus to the debugger (less of a problem these days, but I remember this being a pain ~10 years ago).
Sometimes you may not want to pause execution. Adding a print statement is often faster than starting a debugging session - especially in languages like Common Lisp, where you can simply recompile a single function of a running program. Another benefit of print statements is that they're append-only, not self-overwriting - that is, I can stick one inside a loop and quickly collect a bunch of values to review, or even copy over to another tool for analysis.
A modern debugger is a powerful tool (especially if the language you're using isn't itself very powerful). It's worth knowing your way around it. But that doesn't mean you shouldn't be using simple print statements whenever that's faster or more useful.
If you use something like Symbolics Genera or CLIM, the printed output is actually still connected to the data. Thus you can use relatively primitive PRINT functions and still be able to drill into the objects later.
I use often in Lisp the INSPECT function with a GUI inspector. Each call to INSPECT puts the data into the inspector. For example (inspect (list :loop-i i :value n)) puts the list with the data into the inspector. The inspector has a history, which then allows me to see the various items. Thus this is similar to a print statement, but records the actual objects into a separate tool.
For the sake of completeness, I'll add that the output-connected-to-data works to some extent with Emacs & SLIME as well. These are so-called "presentations" - if you print an object, SLIME will connect the printed text to actual Lisp object, which allows you to inspect it later, or even copy and paste within the REPL - as long as you copy and paste the whole "presentation text", the underlying association will remain.
Sometimes it's just easier. Especially if you have a nice incremental build system or an interpreter to which you can just send expressions and definitions and see the results.
Edit: also, you don't need to remember to weed out debug prints, you can, in almost all languages, define a function or a macro to do that which can be undefined or an ignore function if not built in debug mode. With cpp or Lisp, that'd be a compile time decision, and I suppose many languages could optimise out a function that is defined to just ignore it's arguments and do nothing.
It's slow and inefficient, you add the debug print, then you need to recompile the program, maybe you need another debug print, recompile the program, and so on, and then you must remember to delete all the debug prints that you added! And let's hope that your debug print didn't add some strange side effect (they might have!).
With a modern debugger you could print everything you want, at every memory location, you could set watchpoints, isn't it better than printf ? Also where you printf on an embedded system...