Interesting discussion! You make references to database tech so what I describe is known to you but I'd just add some obvious thing in case it isn't for someone:
If something is mutable in real life, such as a child's height, then each measurement (sample) is timestamped, and it'll not lose its validity for this timestamp. This is called valid time. Beyond this, the wall time of the entry may be recorded as well, called the transaction time in bitemporal terms. It is possible that the reading was erroneous or entry was fat-fingered, so a new tuple is created with the (now hopefully) correct weight with the same valid date but a new transaction date. So, again, a new, immutable, persistent entry was made.
Databases such as DB2 implement features of SQL:2011 such as temporal tables. They allow the storage of such immutable entries and provide the collapsed (temporally resolved) views. Also, PostgreSQL uses the implementation technique called MVCC which purposefully does the thing you seek to avoid: via Multiversion Concurrency Control, preserve the snapshotted relations as they were at the beginning of a transaction, to ensure Isolation of ACID in the face of concurrency.
To me it seems that it's perfectly okay and desirable for observables to stream immutable pieces of data, i.e. values, while not engaging in an overly early binding to an optimization strategy that sacrifices the temporal aspect at the earliest moment - especially in a tool that claims to be a version of Functional Reactive Programming in its one-sentence summary.
It is possible to have reducers (scan) that collapse a primary, immutable measurement stream into required temporal resolutions. For example, one such resolution may do away with both valid time and transaction time, just emitting changes, and maybe some 'last measured' or 'last updated' time. Some other reductions may yield analytics, for example, to visualize how often certain values change, or how often values are revised due to reading or entry error. Also, even the most elementary reductions such as key=child may carry with them the relevant timestamps.
Deeper analytics may apply some applicable smoothing of the data over time, e.g. a child's weight might be smoothed via LOESS or just cubic splines. Also, the velocity of weight gain may be modeled as the differentiation of the weight over time. We're walking into proper continuous time FRP: this differentiation might be performed via some proper numerical technique e.g. using a five point stencil with backward finite difference.
I used the child weight as an example, but it's quite similar if one implements game-like user interactions where timing matters a lot, or consistent views over financial data streams on a trading platform.
All in all, I don't immediately see how mutability would add utility in this context, but I'm not familiar with MobX constraints which is why I made more general comments which are not new to you but might be interesting to someone else.