I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors.
You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.
If syntax is all that matters, then sequential code is great, but there's more than that for many tasks.
(In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)
If you don't need the performance, you can get back to the dynamic-language world by boxing everything (.boxed()). The generics approach lets everything be compiled down to a single state machine, exactly like Iterator.
The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing the type system to store the futures chain. Combined with the very strongly typed nature of rust, even with experimental language features like “impl future<xxx>” the code becomes impossibly hard to reason about.
For example, the result of future.or returning a future bool is not the same type as the result of future.and similarly returning a future bool; and a two-level future evaluating to a future bool is not the same type as a one-level future also evaluating to a future bool.
async/await cannot come soon enough.