Goto has a problem, it breaks the structure of the code. For does not have this problem. Thus, you should avoid goto, and there is no reason to avoid for. The fact that you knows how to write both changes what?
Actually Goto doesn't have a problem; And it wouldn't matter in modern languages that deny access to that low-level instruction.
In basic you can use your labels and goto statements to create a hierarchy of dispatching routines. And if you're very disciplined about which global variables you use as flags to control the execution flow, i.e. which goto statement gets selected next, and which variables to hold return values, you could write a decent program.
The danger lies in that it allows the programmer too much range to produce low-quality code. The negative effect includes too much attention to the implementation of abstractions, instead of its usage. The existence of the goto statements can undermine other abstractions offered by the programming language.
Goto doesn't break structure of the code, programmers do. (I guess that's the whole reason we stopped using it: reducing the risk of making crappy software)
Certainly. Use of goto to implement structured programming is structured programming, but if you're implementing control flow structures that are provided by your language anyway why are you bothering to use goto? The result will be slightly less readable and slightly less maintainable. There remain a few places where a commonly used language doesn't implement the control structure that we'd want to use and goto can be a reasonable choice - the most common example is using goto to implement (limited) exception handling in C.
The point Dijkstra was trying to make is that humans are inherently incapable of dealing with that kind of detailed complexity, and still reliably make useful programs. That's why he proposed that goto should be excluded from all higher-level programming languages.
In my comment structured programming refers to using structured syntax to generate goto statements, so you don't have to see them or implement them yourself. It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design.
To answer your question:
Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!).
"The point Dijkstra was trying to make is that humans are inherently incapable of dealing with that kind of detailed complexity, and still reliably make useful programs. That's why he proposed that goto should be excluded from all higher-level programming languages."
There is a very simple isomorphism between each of the typical control structures (sequencing, choice, and iteration) and its implementation with gotos. It's an easy mechanical translation, in either direction. I don't think Dijkstra was making any claim that spelling these control structures with goto radically increased the difficulty of programming. The important thing was using reasonable control structures (and only reasonable control structures) in the design of your program. Obviously, having the language do it for you is preferred much like any other mechanical translation - but that's not the key point.
"It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design."
I don't disagree with any of that.
"Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!)."
That's still an example of using goto to implement missing control structures, not using goto when the control structure you want is present.
The point is that different languages have different features and even those with similar features may place different emphasis on which to use. By writing code for the 'lowest common denominator' like this, you're missing the advantages of whichever language you're using.
The most obvious symptom would be with libraries; even though GOTOs, loops, recursion and morphisms are equivalent, if most libraries expose APIs in a different style than your code, you'll have to sprinkle translation code all over the place.
It also makes a difference for static analysis, eg. in IDEs and linters. For example, Iterators might give you more precise type hints or unhandled-exception warnings, which makes that style safer (all else being equal).
Of course, the other point is that there are no such 'lowest common denominators'. GOTO certainly isn't, since Python, Java, etc. don't support them. For loops aren't, since languages like Prolog, Haskell, Erlang and Maude don't support them. Recursion isn't supported in COBOL or OpenCL, and took several decades to appear in FORTRAN. Morphisms require first-order functions, which rules out FORTRAN and C, and until very recently C++ and Java. It may or may not be possible to build such features from the other ones, but even so that's clearly working against the language and causing massive incompatibility with everyone else.
Clinging to particular features like this will only blinker us to the possibilities which are out there. In this case, clinging to for loops implies avoidance of at least Erlang, Haskell and Prolog. These languages have a lot to offer, and are/look-to-become the go-to solutions* in the domains of concurrent, high-confidence and logical/deductive code respectively. Clinging to inappropriate concepts dooms us to 'reinventing the square wheel'.
Goto has a problem, it breaks the structure of the code. For does not have this problem. Thus, you should avoid goto, and there is no reason to avoid for. The fact that you knows how to write both changes what?