It's worth noting that the coding climate has changed considerably since 1987. Modern goto-less languages, such as Java, include break and continue statements that can target any enclosing block; many of the example programs that people suggest using gotos for end up basically using these forms. It's worth pointing out that these multi-level break/continue statements allow you to build any reducible control flow graph (that is, the only thing you cannot do is construct a loop which has two entry points; incidentally, these constructs are also the best way to ensure that the optimizer gives up).

Optimizers have also gotten better over the years--it would be fairly easy to transform the idiomatic find-loop pattern based on flags to the one that uses the goto. There's also been a shift to using basic block-based optimizers, which means that the optimizer sees a loop statement and something built entirely of gotos as completely identical anyways.

So, in the end, the goto debate is moot: there's no real difference in performance either way these days, and we've renamed the goto instruction to break which sidesteps most of the puritanical section of the debate.