It certainly looks like the author has given careful thought to making this performant, but I am skeptical about it at scale. While OT means there should be fewer updates than CRDT, you still wind up with a fair amount of them, and you have to periodically rebuild the base document from accumulated steps, which can be quite large.

Assuming your backing store is Postgres, I’d experiment a lot with the various column storage strategies, at various sizes of documents and varying amounts of writes. The TOAST overhead can become a huge bottleneck.