I learned to program on MS Basic on a CP/M machine and made heavy use of GOTO. When I started learning structured programming I had a hard time understanding how program flow could work without GOTO, so GOTO was harmful to some extent because it ingrained certain expectations and habits that were palpably bad and an obstacle to learning, but probably because I learned to sue GOTO in an undisciplined way.
One of the nice things about programing in Basic back in the day was you had complete access to the hardware. You could POKE a memory address and see a dot or character appear on the screen. Basic was easy to use, but closer to assembly than modern languages in some ways even though it was interpreted. BBC Basic was really nice because it had high level constructs and low level system access.
That's the trigger for me: after more than one flag and the complex states involved, I may refactor the code using goto because it can actually be a cleaner solution. Programmers need to be less dogmatic about this case.
Djikstras problem with GOTO was that the source code structure does not correspond to the execution path. GOTO turns the execution into a state machine rather than a nice tree. Avoiding GOTO by implementing a state machine with flags is just creating the same problem one level up.
The problem with GOTO is not the keyword itself, it is what it does to the code.