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