As the article described, JS engines are not implementing features in "spec order". I expect async/await to get wide support fairly soon. (Though my opinion doesn't count for much. I work on SpiderMonkey, but I'm not the one who'd be finishing up our implementation, and I don't know where JSC and Chakra are on it.)
It's a bit of a funky one because it expands the scope of ES into what has traditionally been rendering engine territory (as in, an event loop). But I haven't seen resistance to it.
It's not really that big of an issue for it to still be in the standards track, async/await can be emulated using ES6 generators - in fact, if you target ES6 with the TypeScript compiler it will just implement a generator for you to handle the async stuff. I'm not certain if babel or any of the other transpilers do it yet, but it's not that much of a challenge.
Of course, it will be nice to not need transpilers and I know a lot of people were hoping ES7 might be the end of it - but I don't see it happening anytime soon. Hopefully, though, more standards will be amenable to shims like this, so at least we can get them now while waiting on browser support. (That said, I hate web apps, this stuff drives me mad. I'll stick with GTK and WPF).
I've been using the Babel transpiler to get async/await, and the code is so nice. Showed it to a JavaScript-hater and he gushed over it for 10 minutes -- then repeated the same comments to his boss (my client), which was awesome. :)
But I'm hearing that both the Babel and TypeScript implementations leave a lot to be desired with performance. Not so bad that it gave my use case a problem, but I use NodeJS, in part, for performance.
I'm also targeting browsers (and hybrid apps) with some code, and I've recently jumped from Babel/ES6 to TypeScript, so I can get the support via generators, but again I'm hearing of performance issues.
Getting first class optimized browser support is where I'll feel it's truly awesome.
http://www.2ality.com/2016/01/ecmascript-2016.html