However, it's generally accepted that using goto every now and then to brake out of multiple nested loops is better than creating flags and adding checks to the conditions.
If you're a beginner, though, it's better if you avoid it. At least until you create some criteria of when to use it and when not to use it.
When my students ask me this question, I explain in the following way:
Monopoly is a very simple game. Everyone has played it, and invariably, people modify it with their own "house rules". A rule that you get money if you land in free-parking, or new rules about going to and staying in jail, bankruptcy rules, partnering rules, etc...
Imagine going to a friends house, and they are using house rules. Ok, not a problem, you just have to learn the rules, and use them a while, and you're good.
But what if they don't tell you the house rules. And what if there are so many of them that they keep popping up, and interacting in strange ways that are totally foreign to how you thought Monopoly was supposed to be played...
A goto statement is like a house rule. Programming is hard enough to understand when you can reliably assume that you start at the top, execute 1 line at a time, going down, one line at a time. Using a goto statement throws that assumption out the window, and all of the sudden, the game is uncertain. It's a new and uncertain rule.
Yeah, goto's seem fine to YOU if you wrote the program, but if anyone else wants to understand it, you will have to explain it to them. It's your house rule. If you don't explain it, others will get frustrated trying to figure it out. And no one will want to read your code.
No one will want to play your weird game with all of the house rules. We don't care if you think your game is good, it takes too long to learn to play, and no one else understands it.
The bottom line is that if you use goto statements, real programmers, skilled and practiced professionals, who are worthwhile to associate with, will not want to read your code. And many of them will not want to associate with you because of that, at least professionally.
If you insist on writing bad code, there are plenty of ways to keep doing it without goto ;).