Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
By adding extra useless variables, as I originally pointed out. And introducing a sea of "&&"s. I guess at least it looks more like a bowl of pretzels than a dish of spaghetti.
Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
In a language like C++, unless there's a "try" block within the function, they are exactly the same as a "return" as far as that function is concerned, and can be invoked from the same places. I don't see why you think that that's acceptable if return isn't.
If you look at the FAQs for the Go language, the designers explain why they think exceptions suck in general, and why they largely replaced them with multiple return values. So not everyone shares your enthusiasm for exceptions, which are really just a kind of "return" statement on steroids.