One huge sadness I have is that when you have a callback in .then or .next, your handler doesn't get a gratis reference to what you were listening to. I'd love to have this be a better record. DOM is so good about having thick events that say what happened, and it's so helpful, sets such a rich base, but js snubbed that path & left passing data in 100% to each event producer to decide as it will. Consumers can craft closures to seal some data into their handlers but it sucks compared to having an extensible data flow system. We're kind of sort of finally fixing this crime the hard way by standardizing async context/async_hooks, which is a whole new ambient way to create context that we can enrich our async events with, since there was no first class object to extend for having omitted passing in the promise to the promise handler. https://github.com/tc39/proposal-async-context
Also worth pointing out, maybe arguable as a hazard tale, observables was proposed a long long time ago. There's still a ton of adoption. But it also feels extremely similar yet notably apart & worse ergonomics than async iteration. It's imo a good thing it didn't get formalized. https://github.com/tc39/proposal-observable
Alas one reactivity I really wish we had had is object.observe (note: different API than observables), or something like it. Undoing good specification work & saying, 'yeah, if users want it, they can implement it themselves with proxies' has lead to no one doing it. And you can't just observe anything; whomever is the producer has to up front make the decision ahead of time for all consumers, which turned a great capability into something first boutique then quickly forgotten. Alas! https://esdiscuss.org/topic/an-update-on-object-observe
I ack your ask, and there's no shortage of options that are pretty damned good. But I feel like we are still in a discovery not deployment phase, still delay competing because we have a lot of terrain and idea space to consider. Before we pick, standardize & ship one.
To be fair, Observables and especially Observable composition has a rough learning curve and many frameworks like Svelte intentionally prefer implict reactivity and avoiding things like explicit Observables because they are seen as too complex/"too hard" for the average developer.
(Then you get awful worst of both worlds frameworks like Angular that sort of rely on Observables but yet also don't trust teaching Observables and wind up with code that isn't properly Observable and so also has all the code for implicit reactivity and is full of nasty escape hatches that cause all sorts of composition problems and unnecessary side effects.)
Observables are in position to be adopted by ECMAScript in a future spec eventually, but they are still only at Stage 1 of the ES proposal process, and also Observables don't exactly replace Promises so much as extend them.
An Observable can be thought of as a "stream" of promised values rather than just a single promised value. It's a somewhat different paradigm. From the Observable perspective a Promise is a simple Observable that produces a single value and completes immediately after. So you can see Promises are useful in an Observable world as something of a building block.
A good resource on Observables can be: http://reactivex.io/
It's focused on the main cross-platform library for Observables (ReactiveX which has implementations in .NET, Java, JS, more), but a lot of it is applicable to Observables in general and it has a lot of good "marble" diagrams that can help show why Observables can be powerful.
The dry Stage 1 ES spec itself is here: https://github.com/tc39/proposal-observable
Here is the proposal: https://github.com/tc39/proposal-observable