Here's the point in time where we return to how monads are great.
What Sustrik asks for here is an imperative context where failure is a native operation. Obviously, this is most useful in a delimited way and this is exactly a maybe monad.
People had this argument in the late 1970s and your viewpoint won, although nobody seems to have noticed. Of course you need break or return or something like that to write a linear search that doesn't have a confusing condition variable.
It's one of the reasons why I wish more languages had a generalized switch statement (i.e. one that accepted arbitrary code as conditions, not just constants compared to a single value), preferably with a way to (explicitly, preferably) code a fall-through.
It means that you cannot necessarily translate it into a jump table, true. But it means that you can write code much more concisely, on the flip side. And it remains slightly readable.
It is a part of the structured programming idea to make modules callable by a "shorthand".
It is not in the spirit of structured programming to make use of flow control flag variables.
But if you extract each piece of code that doesn't fit the structured syntax into a separate function you'll end up with zillions of small functions witch have no clear semantics by themselves (only when considered within the context of the calling function). That's probably the most unreadable coding style I've seen in my career.
I did not say it was recommendable. I just said that that was the structured counterpart. Your counterpart is not.
Also I believe most structured programming advocates have no problem considering leaving a loop in the middle as a valid programming structure.
What Sustrik asks for here is an imperative context where failure is a native operation. Obviously, this is most useful in a delimited way and this is exactly a maybe monad.