The solution looks very interesting for use cases that fit exactly in their model: state-based replication of full documents. I also relly like the idea that concurrent versions of documents are natively managed and conflicts to be explicitly handled by the application. But to me there are a few drawbacks to their approach compared to the library I am building.
The first is that it does not support operation-based synchronization where instead of pushing the JSON object and looking for difference a functional operation is pushed to other nodes. Not having that option means that one needs to handle batch updates in a different way or they may result in having to push a large bag of data to the server. It may also be harder to impose complex access rules, here if the user has the rights to modify the object it can do whatever it wants with it by sniffing the network, even breaking application invariants. Mathsync library only manages pulling from the server and application developers have to choose how they push data to the server which can then easily enforce invariants.
A second issue is about synchronizing the whole document to the client. Usually there are fields which are usually set by the server and not meant to be sent to the client. It usually is of no harm, but sometimes sensitive fields may force one to split a logical document in multiple parts, which look to me a going agains the framework. Even when safe, it means the payload transferred to the phone is increased.
I guess they aknowledge those limitations, for example my second concern is mentionned in the talk, because it allows to build powerful applications with very few thinking (much easier than my own library, especially since the library support for serialization is awful for now). But for more complex applications it may be interesting to have more flexibility, at a higher cost.