Async/Await can definitely increase the complexity of the codebase and make stack traces difficult to interpret (especially if you aren't clear on what is happening under the hood), but if you work on any sort of web-based/distributed system, with lots of back-end database/API calls, the performance gain is hardly negligible.
Sure, you won't see much of a difference in response times, but resource usage gets dramatically better, and with it the ability to scale.
If you're working with ASP.Net and you're not using Async/Await, you're doing yourself a disservice.
If that's not your scenario, well then, yeah, dealing with Async/Await is probably not worth the headache.
I do work on web based systems and I can tell you, without a doubt, that the performance gain is bugger all.
I flatly disagree with you, this is exactly the cargo-cult programming I'm talking about.
You're thinking about it totally wrong. Async/await is useful if you have a million pipes, but need 2,000,000. Thats millions of requests per second. Virtually no ASP.Net programmer has that need. They usually need 10 or 20 pipes per second, but they need really, really fat ones. Async/await does not make fatter pipes, it lets you use a single pipe as multiple pipes. But for decades IIS already, by default, supplies loads of pipes.
To make it clear, practically speaking, for virtually every asp.net programmer in the world, async/await is utterly pointless.
It's ok for external website calls. Or something you really need to multi-thread. Like the once in a blue moon tasks.
I work in ASP.Net, I rewrite bad async await code, get rid of it AND improve the performance by orders of magnitude.
Performance problems are almost always, in my experience, SQL bottle necks, bad EF queries or stupid loops. And I have fixed serious performance problems for various businesses. Once in 12 years have I seen IIS running out of threads and that was in 2006 when CPUs sucked. And that was fixed by, amazingly, fixing a bad SQL query.
Littering several hundred 40ms controller calls with asynchronous EF calls that run in 3ms won't make your site faster. Fixing that shitty report that locks 20 tables and takes 2000ms to run causing multiple deadlocks and gets called 5 times everytime someone opens your dashboard because you suck at JavaScript will. Put all the async awaits you want into that bugger, it's still going to screw your site over.
Async/await is a load of utter nonsense for the vast majority of MS customers. And yet now I see people using it for the most asinine calls that clearly do not need it.
Using async/await with desktop GUI apps is basically a no-brainer. Nobody likes applications to randomly lock up and this is a way easier way to solve the problem than the old ones.
Sure, you won't see much of a difference in response times, but resource usage gets dramatically better, and with it the ability to scale.
If you're working with ASP.Net and you're not using Async/Await, you're doing yourself a disservice.
If that's not your scenario, well then, yeah, dealing with Async/Await is probably not worth the headache.