To each their own but the notion that the debugger "will not scale to hundreds of processors and terabytes of data" just seems bizarre to me. If a debugger cannot scale to such quantities (which on its own can analyze a lot of data because it's running on the same/another system), then why could I manage to see what is going on? I guess what is meant here is that with sufficient knowledge about the codebase I'm working on, I'll be able to localize the issue much quicker than a debugger, simply because I have an understanding of what to actually look for. But I still don't know why a smart debugger couldn't help me localize the issue.

The one thing I agree about is that debuggers got stuck in a point in time and they cannot do much more than set a breakpoint and trace some code (with exceptions) - but this is not a limitation of the concept, it's rather that the tools we have today often fail to help us. We resort to using printf() instead because then we're looking at just one variable and when it's printed, rather than stopping the whole program or hitting the continue shortcut 50 times.

It's why I've been researching the topic quite a bit myself with some other ideas than "stop the whole thing and look at state". One thing I found is that if the debugger is not integrated into your workflow (it's not working by default after you compile/run), you'll be much less likely to actually use it. Another way to look at it is: would you still not utilize the information the debugger displays, even if it displayed the state at a line you highlighted immediately?