Asynchrony is not concurrency

The author does not seem to have made any non-trivial projects with asynchronicity.

All the pitfalls of concurrency are there - in particular when executing non-idempotent functions multiple times before previous executions finish, then you need mutexes!

You don't need mutex in async code, since there is no parallel execution whatsoever. In fact languages that use async programming as a first class citizen (JavaScript) don't even have a construct to do them.

If you need to synchronize stuff in the program you can use normal plain variables, since it's guaranteed that your task will be never interrupted till you give control back to the scheduler by performing an await operation.

In a way, async code can be used to implement mutex (or something similar) themself: it's a technique that I use often in JavaScript, to implement stuff that works like a mutex or a semaphores with just promises to syncronize stuff (e.g. you want to be sure that a function that itself does async operations inside is not interrupted, it's possible to do so with promises and normal JS variables).

See this is what the OP is getting at, this is only true for async implementations that don't have any parallelism. That doesn't have to be the case, there's no reason that your javascript runtime couldn't take

    await foo()
    await bar()

and execute them in two threads transparently for you. It just happens, like the Python GIL, that it doesn't. Your JS implementation actually already has mutexes because web workers with shared memory bring true parallelization along with the challenges that come with.