It's not quite that cut and dry. As soon as you have more than one thing with this sugar, you get composition issues—is () throws async -> () a Result<Future<>> or a Future<Result<>>? More likely what you want when you're inside the context is to have a set of "effects" rather than a nesting thereof. This is a common problem with composing monads in functional languages, and there are complicated libraries built around monad transformers or other formalisms to try to regain composability.
I think it would nonetheless behoove us to integrate Result better into the language; if nothing else, it would be great to extend ?, ?? and other optional-related operators to also work with Result. Like much of the proposed API here, though, it's probably best to consider that additively once we get the basic type in place.