Sigh. Yes, the Mongo oplog and RethinkDB changefeeds are superficially similar. They are both for feeding changes, just like a paper airplane and a passenger jet are both for flying. And yet there is a world of difference.
Leaving aside reliability and ease of use, let's focus on correctness. RethinkDB lets me query a database, get initial data, and then get all the subsequent changes to that data. Notice there is no race condition there.
You can use this to implement systems where when a user logs in, gets the initial data loaded, and then subsequent changes are sent as they happen. Even if the same data is modified by someone else during this time (e.g. during the initial load), things will be processed correctly.
Comparing this to attaching a processor to a feed of all operations in the database doesn't make a lot of sense, because the oplog doesn't provide the same functionality.
While the oplog does provide some semblance of RethinkDB's changefeed, it's not nearly as powerful. With Rethink, you say you want a query, and rethink will let you know about changes to that query. Mongo just says "hey, here are operations that were done", and leaves the reconstruction to you".
So I guess Mongo+Meteor match up with RethinkDB... sort of.
It's also worth noting that changefeeds are highly scalable: you can run tens of thousands of them on a single node, and scale them out linearly from there (even as they're scoped to specific queries.)
Obviously the performance characteristics will be impacted by the volume of changes that arrive to the database, but the architecture to support this is highly parallelized (all the way down to cores on the CPU.)
