Interesting. This probably varies by tech stack, but in my experience debugging concurrent/async stuff is where I will actually lean away from the debugger for fear of that kind of timing skew.
The case they are describing is when you know exactly where the error appears, but do not know how it appears. So you put in one breakpoint that will be hit exactly once when it rears its head instead of continuing over breakpoints which causes the timing skew you are talking about.
In any event, standard console logging is an abomination and there are much better encoded logging techniques that are exactly as usable and just as easy to add to your code, while not introducing material timing skew.
