They're all artificial examples: one could assume that the tasks in #3 are intended to be executed serially. Though there aren't any data dependencies expressed between the different calls, perhaps ordering could be important for other reasons.
The async article linked from this article has a toy example for this concept where the result is unused, but most of the time you would be passing the result somewhere. If you were using typescript it could fail at compile time when you try to pass a promise instead of the expected type. Even if you're not, you should notice it never work in your tests.
Still, I think it is easiest to never mess up if you await as soon as you have a promise value. In many common cases this is easy enough.
const userPromise = fetchUser(id)
const itemPromise = fetchItem(itemId)
// Do stuff, maybe even more async stuff
const item = await itemPromise
const user = await userPromise
Since those promises haven't been awaited until later in the code, they could throw and result in an unhandledRejection, which would be pretty bad. Promise.all is much safer since it instantly awaits both promises.