Yes, sorry didn’t mean to suggest you didn’t. Comment was more to clarify to others as the simplistic “it’s faster” can cause people to misunderstand the nuance, which is important as the developer UX of async is worse than sync. I believe we should stick to sync unless there is a significant reason not to.
The trouble with all these things is what the definition of faster is. If it’s “requests per second” then yes these async frameworks are incredible on these benchmarks with their somewhat simplistic view code (I haven’t looked in detail at the one linked, but many often are only echoing back a response).
Really for the vast majority of developers the speed that matters is “time to first meaningful paint” - the time it takes to get a webpage to display on the users browser, or for an api the time until the response is ready to be passed by your front end code. Async doesn’t increase the speed at which that will happen, except in some situations with heavily paralyzable IO within a view.
It is however true that you can get more out of your hardware with async if your are handling 10s or 100s thousands requests per second. Very few of us ever get close to that though.
(Again not suggesting you don’t know this, commenting for others)