Why not both? It doesn't have to be either/or: async/await is a great monad for cases where you need a simple imperative flow. Rx and the Observable pattern are great for cases where you have more complex data flows with complex needs like backpressure support (throttling and buffering), and complex time management.

Each has very different strengths, and it's very easy to work with both together.

    const someStream = Rx.fromPromise(myAsyncAwaitFunction())


    const arrayINeed = await myRxObservable.toArray().toPromise()

let val = await Thing();

Vs

Observable.of(thing).subsribe((res)=>{call back}

For all(most) cases where you only need to hear back once

If you only need to "hear back once", then yes, Observables are probably overkill.

But again, it's a false dichotomy, and your second example isn't much different from what await essentially rewrites to:

   Thing().then(val => /* call back */)

The benefit to async/await is that the runtime does the rewriting to Promise callbacks for you. But you can use both and get that advantage for both. Rx has supported converting to/from Promises since the beginning. Working with both is easy.

    let val = await observableOfJustOneThingINeed
      .take(1) // I just need one, I don't care if there are more
      .toPromise()

You don't have to manually subscribe, you can use a Promise and await it.

There are cases as well where maybe you want a linear async/await flow in the middle of an Observable flow, too.

For instance:

    let jsonStream = searchFieldChanges // observable of search field change
        .debounce(300 /* ms */) // don't do it too often
        .flatMapPromise(async (search) => {
            const request = await fetch(`${searchUrl}?query=${search}`)
            return await request.json()
        })

ETA: To reiterate the point: both tools are better together and it's not one or the other, it's like most tools finding the right one for the right job.

What RX gives you is a smooth flow to the last callback. Async is admittedly less flexible but the only way I know of to trigger asynchronous flow without a callback.

I worked in the C# world for a while and I'm still in envy of how clear and powerful good async support is.

Under the hood, async/await is using callbacks into a finite state machine. JS Promise and C# Task<T> (which are very similar in design, for obvious reasons) are both still driving the operations in an async/await function, the JS runtime, C# compiler (or TS compiler), is doing the heavy lifting of converting imperative looking code into a finite state machine for Promise/Task callbacks.

You can't avoid callbacks in an asynchronous flow. async/await is just a conversion between imperative looking code and a callback structure. It's a great win for developers that we've built such conversion tools (thanks to work on monads in languages like Haskell and OCaml).

Rx is for higher-order asynchronous streams where you have multiple events over time. It doesn't have the beauty of async/await because it's a much more complicated abstraction than the basic monad of Promise/Task. If you have a stream of events over time you can use Rx and if you have just one Promise at a time you can use Promise/Task and thus async/await. (The difference between I want to know every click of this button and I want to know just the next click of this button.) Most applications are a little bit of column A and a little bit of column B, and you don't have to pick one or the other, you can use both side-by-side.

Async avoids callbacks by restoring your calling context under the hood just like the compiler does for normal function calls and callbacks. It just does it in a way thats clearer IMO