The mobileapps service is currently using RESTBase's key-rev-value storage to persist materialized representations of content, re-formatted for use in native applications. I suspect that this is at least in part simply because It Was There. However, given the problematic nature of this storage, I think we should re-examine this decision.
The raison d'etre of RESTBase's k-r-v data model and retention was the storage of materialized representations of content in a format suitable for Visual Editor. This materialized representation takes a significant amount of time to generate, and thus must be pre-generated and stored in advance. This is done for every render, of every revision, of every document, across all projects, despite us only ever accessing a tiny subset. Additionally, retention semantics dictate that past records can only be removed after the expiration of a TTL, with a clock that starts only after it was superseded. These semantics are necessary to support concurrent editing. Implementation of these semantics came with a number of trade-offs, not least of which is a not insignificant amplification of storage.
The mobileapps service doesn't seem to require the same elaborate retention needed for editing, and transform generation is on the order of 4 seconds 99P (as opposed to minutes in the Parsoid case). If transform latency were low enough, and/or cache hit rates high enough, then perhaps we should rely on Varnish as we do with other content. And given the expense of pre-generating and storing mobile content for every change, regardless of how little of it is actually accessed, I suspect we could easily justify significant engineering effort in optimizing transform latency.