Admittedly I have yet to find a use case for GOTO in C#, maybe to break out of deeply nested loops but since the advent of Linq, nested loops became rare in my code.
It's not necessary, but an incredibly valuable convenience. Without goto, to machine generate anything but simple code while remaining at least as performant as hand-written code you must operate on some sort of AST. With goto you can hack together incredibly complex solutions with nothing more than brain-dead textual concatenation of syntactic constructs. For example, if a language only supported "break N", then to generate code that broke out of deeply nested loops you'd need to explicitly track loop depth in your generation code. Tracking depth while writing modular generation code inevitably forces you into building some sort of basic AST data structure, which is often too much bother, even if you can use somebody else's library for building the AST. Whereas with labeled goto all that matters is that you generate unique label names, which is almost universally accomplished by incrementing a simple counter (e.g. goto L27). And this is useful even if you're already building a fine-grained AST. Your generator need be only as complex as you need it to be, not as complex as the target language requires.
In languages without goto, sophisticated generators often resort to using switch statements. Target-language authors argue that their compilers are sophisticated enough to generate code from switch statements identical to code using goto. But these claims are just like claims about JIT compilers--compilers do generate good code for many idiomatic constructs, but quickly fall short in complex, real-world scenarios. Even clang and GCC can very quickly degrade to generating if/else ladders rather than direct jumps or jump tables, and those compilers have some of the most sophisticated and capable optimizers.
