Two people try and add a y:2 to the object. If you treat the object as a string, you can end up with:
{y:2,x:1,y:2}
... which is invalid JSON. If you do string-level operations, there's heaps of ways the JSON can end up invalid or just plain wrong. In comparison, using OT if two people apply a "Insert y:2 into the object" operation, the object will be edited correctly at all sites.
Joesph's reply is absolutely correct. I just wanted to add that JSON is a special case of what I noted above: OT is more of a protocol than an algorithm, it takes in operations and performs a transformation on them. It's up to you to decide what those operations are and how to transform them.
The canonical example of a text document with operations consisting of inserting or deleting strings of characters is a little error-prone, but in the context of humans editing text in real time, there's an assumption that they will correct any visible artefacts.
However, when you have structured data created and consumed by algorithms, your tolerance for artefacts goes down to nothing, and you need to choose a different set of operations and carefully design the transformation function.
In between structured data and unstructured text there is also text with semantics. As noted above, you can ignore that and leave it up to humans to fix it, or you can bake some smarts about the text in. There are existing products that treat numbers as a special case, for example. It may not be worth the effort, that's a design choice.
Anyhow, this is a lot of blowhardiness just to say that OT isn't an error-free way to synchonize strings, nor is it just one algorithm, it's a protocol and part of the design process is deciding when and how to go beyond plain text and the obvious transformations on the operations.
Getting OT-for-JSON working involved a lot of cases, but it was certainly tractable. The tricky algorithmic code is 440 lines long.
XML would be much more complicated to get right, but certainly possible if you're mad keen on XML.