Print Debugging Isn't Wrong. It's Just the Wrong Tool Sometimes.
A console.log or print statement is fast and honest about state over time; a real debugger is better at everything else. Knowing which situation you're in is the actual skill.
I still reach for print statements constantly on side projects, and for a while I felt a little guilty about it, like using a real debugger was the "correct" way to do things and print debugging was a beginner's habit I should have outgrown. Building and debugging a personal tool solo, without a team's code-review process pushing back on my habits, is actually what made me notice that both are just tools, and the mistake is only ever picking the wrong one for the problem.
Print debugging wins when the question is "how does this value change over the course of many iterations." A print or console.log inside a loop, run once, shows you the whole shape of that change at a glance — a debugger would make you step through the loop one iteration at a time, or set a conditional breakpoint and hope you guessed the right condition, just to see the same thing.
A real debugger wins when the question is "what is the full state of the program right now." Pausing execution and inspecting every variable in scope, walking up and down the call stack, evaluating an arbitrary expression against the live program state — none of that is something print statements can do, because print statements only show you what you specifically decided to print, in the exact spot you decided to print it.
The failure mode I actually see myself fall into is using print debugging for a problem that's really about state, not about change over time — adding print statement after print statement, each one answering a slightly different question, when a single debugger session with a breakpoint and a variable inspector would have answered all of them at once.
The other real cost of print debugging is cleanup: every print statement is a line you have to remember to remove before committing, and on a solo side project with no code review to catch it, "temporary" debug output has a way of quietly surviving into a real release. A debugger session leaves the source untouched.
Neither tool is training wheels for the other. The actual skill is noticing, within the first minute of hunting a bug, whether the question in front of you is about change over time or about a snapshot of current state — and picking accordingly.