Yes, there is great utility in this approach! For one, most concurrent text editing, rich or not, is actually quite easy to merge in 99% of cases. But even that aside, when you have data structures or document formats that don't ever have to resolve conflicts—or, more accurately, when conflict resolution becomes something that's naturally done in app-space, on the edges, and not as part of the network layer—then you open up the possibility of offline-capable, collaborative apps that require zero coordination between nodes. A node with changes only has to deliver their content to interested servers and peers, not engage in lengthy conversations about who has the definitive version, whether somebody has to revert, etc. You could build a Google Docs clone that synced entirely over Dropbox!

And in any case, the "merge" part would still be up to the app. The data structures will always be able to merge, sure, but the app could still throw up a dialog box on wildly divergent changes saying, "Hey, some crazy stuff happened here—want to look it over and commit manually?" (Where "commit" means generating new changes to overwrite any undesired changes, since it's not possible to literally undo.) You could argue that we've simply implemented ad-hoc coordination protocols in the app layer at that point, but IMO, that's exactly where they belong in cases where there's no authoritative store for your data. (Which is really the case with mobile, offline-first development.)