I see that google provides api for javascript to collaborate: all clients see the same model. The undates (I believe between model.beginCompoundOperation and model.endCompoundOperation) are claimed to be atomic and durable. This seems to be ideal for single controller - multiple viewers (which refresh on model update) but seems insufficient for concurrent applications, IMO. As far as concurrent controllers are conserved, inconsistent model can result when they all start manipulating the model disregarding the others.
Consider identity counter. You maintain a graph. That is your model. Every node must have their own id. There is single nextID value, in the model. When client creates a node, it increments that field. However, you understand that another client can do the same thing at the same time. They both have incremented the counter from 4 to 5. However, two nodes were added. This demonstrates that shared data access must also provide locking interface. I do not see anything in Google Realtime API. It is not even discussed. Why nobody seems to notice and nobody seems to care?
I think the concerns you have are quite valid for a database, however I would be skeptical about using the Google Realtime API to store data specifically the way that you are describing if you require your data model to have ACID properties. Some constraints that you reference are discussed on this page, and limitations and behavior of compound operations are talked about here.
Of particular interest, as far as your reference to compound operations, is the following from the second link:
The data model in the Realtime API runs conflict resolution on changes that you make to it rather than guaranteeing an operation is going to have an exact effect that you requested. Storing data structured as your describe and performing operations that require locking is not a good options. The first link has a reference that describes how you can use the realtime model to perform shared math.