Personally, I think it should be up to the vendor of the API to determine whether or not an early cancellation constitutes an error. In many cases, cancellation is not an error and emitting a 'nil' sentinel value is perfectly appropriate. I'd be disappointed to see the loss of iterating an asynchronous sequence outside of a do...catch block.
Also, I wonder if this brings an opportunity to revisit the discussion raised by @DevAndArtist around asynchronous sequences and cooperative task cancellation: there's a question mark over whether or not asynchronous sequence 'plumbing' (i.e. asynchronous sequences provided by the standard lib or Swift Async Algorithms package) should be eagerly cancelling themselves and throwing Task cancellation errors at all.
In my mind, this issue is another clear hint that they shouldn't – the cancellation of an asynchronous sequence should be made deliberately by the programmer in the context of its usage.
When you think of asynchronous sequences in this way, the problem evaporates. if an asynchronous sequence needs to somehow cancel and communicate that cancellation, the programmer simply specifies their source asynchronous sequence as throwing, and – if appropriate – creates an error type to match. The programmer specifies what they need, and in turn we trust them to handle the cancellation of an asynchronous sequence as we trust them to cancel an asynchronous Task.
The job of the plumbing provided by the standard library and Swift Async Algorithms then, is to simply and faithfully distribute those elements and failure types – but otherwise, get out of the way.