If Go To statements are bad then why ...

>... are there countless abstractions and programming language mechanisms that bounce you around the text in ways that Go TO could have never dreamed of.

Like? What are those abstractions and mechanisms?

Well written programs can (and do) make use of no such mechanisms, in any case. Where have you seen those? Any particular example that moves the flow the way Goto does?

Exceptions come to mind, and people always point out that its bad to abuse exceptions for control flow (e.g. using them like a kind of goto).

The problem with goto (which is not considered a problem when used in local scope, e.g. for cleanup code within a function) is that it moves the flow of execution away and makes it difficult to track.

A function (or e.g. a continuation in Node) doesn't have that problem: you return back to where you started.

Jumping between addresses is the way how assembler programs/machine code works. A high level language shall abstract, bringing powerful concepts like scopes. If you short-circuit the high level logic by directly using gotos, you will shoot into your foot. Furthermore, the pladoyer "goto considered harmful" was about using high level program structures for the sake of their power. Letting the compiler alone to do the hard work of managing your variables, etc.

Flow of control is what is critical in every application, and goto's allow you to break flow of control easily. That said, a lot of very stable systems used goto's for very specific instances. For example, they would use it to short circuit the if/else/if/else for error handling, cleanup etc. But it was a goto within a single scope, e.g. within a single function. Of course, with that power comes the ability to cut off an important appendage, and in reality the "need" for a goto is really not a need, it is a lazy implementation detail.

Usually what I found is people feeling the need to use goto often just didn't understand how to design or layout the system they were working on, or try to put to many unrelated code segments into a function. As other comments mention, the flow of control changing scope etc cause lead to all kinds of difficult debugging, memory leaks, crashes etc. So not generally a good idea. Smarter to use proper function scoping, return behavior and error codes.

One of my early tasks as a C programmer, back in the early 90's, was taking a C program that had like only 4-5 functions (with thousands of lines of code) in it, and tons of goto's and cleaning it up to be a maintainable system. Engineers all hated that system because it ran fairly stable (somehow), but touching a single line of code could mean days of debugging. Starting over was easiest but took forever to get the functionality correct because of all the jumps to weird places that were not obvious behaviors. That was an unforgettable lesson for me.

I once failed/bailed from a C course because I refused to remove a `goto` and the instructor refused to allow my code to be submitted. Even though it was demonstrably the right thing to do, he was adamant that it was better to have a cascade of `if` blocks with guard variables that made it way more complex and difficult to follow.