I prefers async/await, but I agree with your points.

1) The reduce version with .then() is elegant, I like it. I think in that particular case await inside a normal for is easier to understand, but the version with .reduce is nice. I didn't think of it.

2) Yes, we agree. My example was just to prove that in some cases Promise.all (or a variant) could be avoided, but it is not a good solution.

3) I didn't explain well.

try {

doSomethingSync()

await doSomethigAsync()

} catch(err) { }

In the above example, catch will catch errors inside the doSomethingSync() and inside doSomethingAsync().

On the contrary:

doSomethingSync()

doSomethingAsync().carch(()=>{})

will catch only the async errors.

I just wanted to point out that the 2 syntaxes can lead to different error handling, and that the promise syntax, in this case, is a bit better because you want probably to keep separated the handling of sync and async errors.

A though pro async/await, which is not against promises syntax:

When I start using Unity to make a Pint&Click game, I started using C#. C# doesn't have promises, but it has async/await.

Thanks. Looking forward for another article of yours.