Personally, I don't mind the use of "goto" when it fits. There are very few cases where I can justify using it, but I do use it once in a blue moon.

Do you have any examples of the sorts of circumstances under which more modern compilers are untrustworthy?

It took them years to get the compilers right on the last gen of consoles, at least. Sony spent at least half of the generation simultaneously shipping two independent compilers (common linker) as part of the PS3 dev kit.

Let's not forget that goto fail; happened.

Braceless conditionals are eeeeevuuuuul!

Let's not forget that goto fail; happened.

Braceless conditionals are eeeeevuuuuul!

This is true. Though with the goto fail example, shouldn't the compiler have produced an "unreachable code detected" warning? (Or do they still not have that kind of static analysis there?)

Maybe I'm just spoiled by C# compilers...

Who's to say the project doesn't compile with a bajillion warnings, or that particular warning is disabled?

goto breaks the flow of the program and makes significantly harder to track or predict how a program will execute by just glancing at the code. It also makes silly bugs and mistakes much easier to introduce.
It basically reverts any language back to assembly-level difficulty where you have to follow instruction by instruction to see how the execution jumps around; except that its even harder because in assembly at least you've got an instruction per line; whereas in other languages one expression could be expanded to multiple statements.
I cannot simply place my finger at a random place, start from there, and understand what's going on. Code with goto forces me to go to the start.

Comparing with continue and break is not fair, because continue and break have very clear flow of the program: Just jump your eyes to the bottom of the ending bracket '}' (unless you have deeply nested break and/or continue statements, which is also hard to track and also considered a bad practice anyway). If the code inside the brackets is too long and you have to scroll down too much, again... you're doing it wrong.

goto on the other hand, can jump anywhere, like a flea. It may jump backwards a couple lines. It may jump backwards a thousand lines, then jump again forward another couple thousand lines. You never know where it's going to land and it's very distracting. Not to mention you have to keep a mental model of the state of the program before each jump.
May be you think writing code with goto is easy and convenient. And indeed it is. But when you have to maintain that code a year after you wrote it, or collaborate with other people who need to read and understand what you wrote; goto becomes a nightmare.

You speak as if you never programmed anything of more than trivial complexity. BREAK and CONTINUE can be less clear where there are (many) nested loops or where your 'just jump your eyes' might be to along ways off the screen far below.

GOTO has a label which can be made VERY visible and understandable (I usually place the goto destination LABELS to the far left no matter what the indenting so they stand out VERY obviously) and use a meaningful phrase which makes it quite 'clear' where its expected to be (we should be assuming that it would be used RIGHT not assuming it to automaticly to be used poorly -- as ANY part of the programming language can be use wrong -- actually far wronger than the simple GOTO statement).

I use GOTOs more than a little (where appropriate) and BREAKS and CONTINUE (where appropriate) as well as comments in significant ways to make the code more readable, which is quite an advantage when the programs are many tens of thousands of lines and for situations where a thousand line subroutine is not unlikely.

GOTOs can flatten out/clarify certain patterns of code which otherwise would be a mess of nestings and escape logic (and not just for error recovery/handling)

BREAK and CONTINUE can be less clear where there are (many) nested loops or where your 'just jump your eyes' might be to along ways off the screen far below.

Which is why well written code doesn't do that either. It's a false duality. Goto doesn't excuse other ways of writing shitty, hard to follow code.

GOTOs can flatten out/clarify certain patterns of code which otherwise would be a mess of nestings and escape logic (and not just for error recovery/handling)

This is certainly the case in C or code that is forced to follow similar flow patterns, where a jump to a cleanup stage is often required in lieu of a return. The RAII crowd will claim that this is a fundamental failing of the language. I have mixed feelings on the matter, but it's the damndest thing: hundreds of thousands of lines in our current project, a number of subroutines in the thousands of lines, and no need for goto statements. So I can't really agree with you that its use is a common structural pattern, particularly in situations where you do use RAII constructs (ie locally scoped destructors) to deal with cleanup.

Here's the thing, though. Maybe it's goto. Maybe it's a break/continue on deeply nested looping structures (which we definitely have in our codebase). It sorta doesn't matter which one - most of these direct-jump commands are representative of fundamental design issues, or simple poor code quality in need of refactoring. You've got a big attitude about the wrong thing. If you have a lot of non-local control flow, especially nested, then your code sucks. Avoiding a specific keyword has no effect on that. These are endemic problems. If your use of goto makes completely badly written code only tolerably badly written, that is not an argument in favor of goto, nor is it an argument in favor of other long distance jump instructions.

BREAK and CONTINUE can be less clear where there are (many) nested loops or where your 'just jump your eyes' might be to along ways off the screen far below.

If you have loops or conditionals so deeply nested that this is something you need to actively worry about, then your problem isn't "which language construct shall I use?"