I think it's worth noting that async/await is a bunch of sugar around promises... All async functions return a Promise... and all awaits await on a result or promise resolution. and Errors will bubble out.
This is helpful as many times I'll write a function that simply returns a promise to wrap around an older callback style function. I know I can promisify, but this doesn't always work as sometimes the methods need their context.
As to redux, frankly, I find redux-thunks + async functions to work pretty well together until you need more.
Only downside I've found with this is that Observables feel like more of a pain to test, since your logic gets more tightly coupled to your I/O. Or at least there's more complexity involved in the relationship between I/O and data manipulation. I used them for a Node project via RxJS and ended up just switching back to promises, as it wasn't complex enough of a project to really see much of a benefit from Observables.
The only difference between promises and observables are multiple-emission & cancelation, they shouldn't be any more complicated to use or test than promises. Often I find the main complicated part is the source, everything else is just filter/map functions, sometimes to more streams. All of these individual units are more easily described/tested in comparison to the entire chain (and even then you are only caring about the ends of it).
Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks.
In the redux world, you can see this by comparing redux-observable [1] (reactive / rxjs) with redux-saga [2] (generators)
Rxjs requires a deeper understanding of Reactive programming. Once you understand it, you can write very powerful expressions in a few lines. But debugging is tough and it doesn't translate well for your fellow developers.
[1] https://github.com/redux-observable/redux-observable
[2] https://github.com/redux-saga/redux-saga