Welcome to the forum!
so please forgive any ignorance implied by the question I’m about to ask.
As long as we are clear that anything that I write is just my opinion and not the gospel truth. 
I’m also coming from the Angular world
I’ve spent significant time with AngularJS but I’ve never looked at Angular because despite the changes it didn’t look like it was getting away from being some sort of OO leviathan (and I was an OO devotee back then). I came to that conclusion when I found myself spending a significant amount of time learning AngularJS but ultimately didn’t feel like I understood web development in general any better.
There is likely nothing wrong with Angular in an enterprise environment for web applications targeting workstations that have direct access to the corporate backbone. But if the target demographic includes mobile users the issue of a JS Budget is a real one.
Angular is just a bit too heavy if you are on a JS budget. And predictions are that average mobile performance will at best stagnate if not decrease due to the continued influx of more inexpensive (and less performant) smart devices into the general market.
promise API for async data access, the Observable API (RxJS) felt like a dream come true.
While I realize that promises are eager, observables are lazy I think it would have made some sense if observables would have been adopted into ECMAScript instead of promises.
As it is, RxJS is a bit heavy for the value it brings when you are on a JS budget. Unfortunately the TC39 Observable proposal seems to have stalled. The current thinking seems to be that it doesn’t belong in the language spec. So short of observables becoming a W3C standard (not likely) observables will require a downloadable library within the browser. Maybe a WebAssembly version will be lighter weight (not holding my breath).
The size issue with RxJS pushed one contributor, André Staltz, to create an entirely new library xstream for his own framework Cycle.js (he only needed hot observables; Unidirectional User Interface Architectures). More recently he devised a specification for “callbags” that enables observable-like behaviour without the presence of an observable library.
the main benefit being that it made it easy to pipe HTTP access and DOM events together to compose user interactions with one consistent API, rather than using one API for HTTP and another for DOM.
I think the general idea is to turn any change that “the system” might be interested in into an event value that can then just be dropped into the network of “wired up” observables that will then route and transform that value to all the essential subscribers.
rather than having local state scattered across a bunch of different services and (maybe) components.
In my view the primary use case for observables is decentralization - when a significant change happens somewhere, the observables are responsible for propagating and transforming these change events to where they need to go - that way each subscriber has complete autonomy over its own local state while only having to deal with change events they are actually interested in.
I feel the main reason RxJS is often bolted onto monolithic stores is because the monolithic store was already in place. Reactivex solved a problem that the unistore couldn’t by itself.
I believe that if you start from scratch and are committed to using observables that you should design your solution around them - and if you do, the need for a unistore will never come up.
FYI: RxJS: destroy the state machine! – Stenver Jerkku / Front-Trends 2016
