No, it's not more clean in the way those are. If you already have a loop, use break or continue. If you don't, it isn't "more clean" to introduce a pseudo-loop just so you can use break.
I'll grant that it would be handy to have a syntactic feature that would be equivalent to "break", but would apply to the current enclosing block. Basically like "return", but block-scoped - which is basically what this is, except for the whole intent/readability issue. I also like languages that let you do labelled "break" and "continue" out of the loop, rather than forcing you to put the label after the loop - IMO labeling the loop itself is more logical.
But we should be cognizant that those features are still extremely close to a naked goto in terms of the ability to reason about the code - it's just a sprinkling of syntactic sugar on top. So if goto is unequivocally bad, then e.g. early returns are also bad for all the same reasons. Conversely, if those features are fine when used in moderation or in well-established patterns (like "if (error) return") - which I believe is the case - then so is a naked goto. It's the cognitive dissonance of people who use them heavily while insisting that goto is absolutely evil, no exceptions, that irks me.
> - which I believe is the case - then so is a naked goto. It's the cognitive dissonance of people who use them heavily while insisting that goto is absolutely evil, no exceptions, that irks me.