At some point, the complexity of the task the program is executing requires complex code.
This is a more profound statement than it appears at first. I'd say that the minimal complexity of the code necessary to accomplish a task defines the complexity of the task itself.
As for GOTO the issue isn't GOTO per se, but implicitly building other control structures like loops using GOTO as a primitive -- a legacy of the very earliest machine languages in which you implemented algorithms using a very limited instruction set. The flexibility of GOTO makes it a good choice if you have only a few control structures to work with; but that same flexibility imposes the cognitive load of figuring out what the original programmer (possibly yourself) meant.
But even if more structured (i.e., limited) control structures available, there are problems where GOTO is the natural way to express them. State machines for example. I've seen them implemented with long if-then-elseif chains or case conditional constructs, but that's just thoughtless programming that obscures what is going on. A state machine is much more clearly implemented with GOTOs, although tail recursion can be a reasonable alternative.