Smalltalk, Ruby, and any language with callcc is nearly as unstructured as it would be with goto (though most of them idiomatically minimize usage, which mitigates this in practice), which is also a part (implementation/optimization prospects are another) that Ruby banished continuations from the core language to an MRI-bundled library starting way back with 1.9, replacing the main uses with the more structured Fibers.
(defun foo-find (foo x &key (test #'eql))
(foo-iter foo (lambda (bar)
(bar-iter bar (lambda (y)
(when (funcall test x y)
(return-from foo-find y)))))))
I don't think having unstructured told in a language is a bad thing, though I think the core language / stdlib having the right structured tools (whether primitives or built in the language itself on top of the unstructured ones) that most code never needs to reach for the unstructured tools is desirable.
This is completely orthogonal to call/cc, because it won't allow you to do this arbitrarily - you get an exception if there's nothing to return/break from anymore.
Smalltalk, Ruby, and other languages in a similar vein beg to differ. And I don't think you could call e.g. Smalltalk "unstructured", either.
On the whole, I'm not really convinced by the arguments presented there. Most async code is effectively linear on any given code path, and thus you don't need any abstraction other than tasks/futures to synchronize. When multiple concurrent tasks are spawned, ideally, the facility that does so should bind them together in a single task that can then be awaited (or not, if necessary). This takes care of resource cleanup, error handling etc.