To maybe add some more details here, when Araq says "structured programming" he is referring to things like [the structured programming theorem](https://en.wikipedia.org/wiki/Structured_program_theorem) where all you need is if-else-while and bool variables.
On the other hand, almost every practical programming language I've heard of marketing itself as "supporting structured programming" has at least one of `break`/`continue`/`return`/`goto` because almost no human seems to think a bunch of bool variables is _always_ easier to reason about. For this reason, these debates about control flow representation remind me a lot of debates about "functional programming" before the "pure"/"purely" qualifers became popular (as in "pure FP"). My experience is that, for good or ill, most programmers come to the term "structured programming" by example, not by that theorem/Dijkstra-like opinions. Break/continue/return are a middle ground between fully unstructured (goto) and purely structured (only if-else-while) in almost every sense.. lexical, logical, etc. Jump targets are limited, avoiding the control [flow charts](https://en.wikipedia.org/wiki/Flowchart) looking like a tangled mess of spaghetti { or equivalently needing a very good decluttering algo :-) That tangle was the "fact on the ground" that sold "structured programming". } So, personally, I think these conversations would resolve more quickly & helpfully if people started using "pure"/"purely" qualifiers or hyperlinks to pure ideas. :) Degradations from "purity" are also almost always "fuzzy". So, that highlights that exceptions are more judgement calls. Also "program structuring" for many non-native English speakers might seem nearly identical to "structured programming". A new qualifier might disrupt that similarity just enough to avoid a debate. :-)
