(NOT A CONTRIBUTION)
A particularly relevant use case for the preemption flag is FuturesUnordered.
In the past, FuturesUnordered could exhibit quadratic behavior in a scenario in which all of its futures begin returning Pending because the task is out of budget. It would continue polling them, because they had been awoken, receiving a Pending every time. See here: Quadratic complexity in FuturesUnordered · Issue #2526 · rust-lang/futures-rs · GitHub
This was solved by arbitrarily limiting the number of futures FuturesUnordered would poll before yielding to 32. See here: FuturesUnordered: Limit max value of yield_every by taiki-e · Pull Request #2527 · rust-lang/futures-rs · GitHub
With a preemption flag, instead FuturesUnordered could simply check this flag before polling the next ready future and yield if it has been pre-empted. This would have the effect of making the limit on the number of futures dynamically determined by the runtime according to the budget the task has, rather than a fixed value of 32. This would avoid unnecessary yields (when more than 32 futures could be polled without preemption) and unnecessary polls (when the task is preempted at less than 32 futures being polled).