You should check out the event-reduce algorithm[1]. It scales in a different way on how it calculates new results based on old-Results+Event. So it can have some benefits over materialized views depending on the data size and how many clients subscribe to a query.
It sounds like you did not read the READme. What you are describing is something that does scale up with more data but not with more requests.
When you have an application where 1000s of users subscribe to different queries, your view-maintainance would kill the write performance while EventReduce does not.
The difference is that with simple caching you have to run full queries again when the cache becomes invalidated. This is often expensive especially on write intensive data usages.
I think the best example for why this is useful is described by david glasser at his talk about the oplog driver used in meteor.js https://www.youtube.com/watch?v=_dzX_LEbZyI
All your assumptions are wrong. Please read the other comments here or at least the readme of the repository. I will happily answer all ongoing questions you have afterwards.
EventReduce is a simple algorithm. It does not care or affect how you handle propagation of writes or how you handle your events, transactions or conflicts.
See it as a simple function that can do oldResults+event=newResults like shown in the big image on top of the readme.
EventReduce is an algorithm and not a database-wrapper. It will not care about your writes or if your database layer is a cluster and so also not affect them.
I encourage you to read the readme and check out the demo.
EventReduce is nothing magically drills out your database and affects the consistency of your write-accesses.
It is a simple algorithm that is implemented as a function with two inputs and one output.
I understand that reading the plain source code is more painful then reading a paper.
There are many different trade-offs between a paper and the current repository with source code.
For me the biggest argument was that EventReduce is a performance optimization. So to be sure if it really works and is faster, you always need an implementation since you cannot predict the performance from a paper.
Because I did not have time for both, I only created the repository with the implementation. Maybe a paper will be published afterwards.
Yes I used it. I actually know it really well.
I also did performance comparisons with mongodb and mongodbs change stream and cursors. What I posted here is just an algorithm. You could now compare it to mongodb (a product) and say it is a "more flexible solution" but I do not see the point in directly comparing it simply based on the documentation of both.