This is by design, companies moving away from Redis because of this did not understood the deal at the beginning, and where looking for something else, so it was a good idea to move away.

Redis is mostly an in-memory database that happens to be disk-backed. With VM it is a different issue, and there are interesting VM uses, but the vast majority of Redis users are using the DB without VM, and as it is, as an in memory store, where the disk dump is used in order to reload the data on startup.

Because this is the Redis way, even developments are focused towards this direction: to use less memory for common data types, and scalable clustering in order to make it simple to use multiple instances.

I see this as a very simple to gasp thing. Just because this is the argument of the discussion instead I fail to see why Mongo should instead not be just considered as an SQL-family DB. It seems more or less a subset of SQL, but implemented with different tradeoffs. For sure they have some good motivations to avoid SQL, but what I mean is that semantically it looks a relational database, while Redis has a completely different data model, so I can't see how the two systems really are a reciprocal drop in replacement and/or comparable solutions.

So I can see how MongoDB can be an alternative to MySQL when used to store a lot (much larger than memory) of row-alike data (call it documents or like you want).

And I can see how Redis can be used when you have memory fitting databases and need very high performances, and in general for all the needs of atomic data structures and complex server-side operations in this data structures. For instance storing or caching timelines, taking leader boards for a game via sorted sets, and a zillion other use cases that are currently running while we are talking.

I can't see instead how MongoDB can replace Redis or the other way around, if not for a very small subset of cases.