I can't speak for Meteor as much, but Derby's bindings support pretty much everything that Knockout and Ember can do. The big difference is how you connect the bindings to model data. Knockout has a generic API that you can pass pretty much any JSON data to. This is flexible, but you end up having to write a lot of glue code to hook it up to whatever type of model you use. Ember bindings only work with Ember models. Derby automatically knows to look in its model to bind data.

Knockout is pretty minimal and fast, Ember has not performed very well in update intensive benchmarks. From our testing so far, Derby is somewhere in the middle if you bind everything, but it has granular control of bindings so you can get it to perform about as fast as Knockout.

This is just one small part of synchronizing clients, and Derby takes care of realtime data syncing as well. Synching data with ember requires a lot of manual server implementation. In addition, Ember and Knockout don't have any way of supporting server-side rendering, while Derby automatically renders everything in both the client and on the server.

You are right that you can't partially implement OT. The way that we handle it is by keeping OT operations on defined paths so that they are separately namespaced from other kinds of updates.