my 25 years of software development, I have never found a situation where the use of GOTO would produce better code
You've never written a good lexical analyzer then. No shame in that. Few people ever have to write one of those themselves. But take a look inside your (f)lex output some time. You'll find lots of gotos.
I used to say this exact thing, until the day I came across a problem where it wasn't true. I had to recode the algorithm every way I could think of, before I could accept the truth.
This is actually still great advice for about 95%+ of all software work. In my 30+ years of professional software development, I think I've done it once. However, if you end up in a situation where you have to code up a true state machine with no real structure to it other than nodes of code connected by control branches (eg: a lexical analyzer), then the natural expression of this is blocks of code connected with gotos. You can try and hide that by wrapping the mess in a case statement with a loop or something, but that doesn't change the real underlying control flow. In fact it *obscures* it.
And again, this isn't me being retrograde. This is well-known among the compiler building community (where the issue comes up regularly). That's why this report was able to find so many examples. It would be a very good bet that almost all the programs it found with gotos contained lexical analyzers (eg: compilers, compiler builders, regex matchers, etc.). These people aren't unrepentant cave-men. They just know something you don't because they regularly work on types of problems you don't.