The "conflict-free" part of the name is misleading. The conflict "resolution" means having some deterministic algorithm such that all nodes eventually converge to the same state, but it won't necessarily mean that the end state looks like it's conflict-free to a human. The algorithm you choose to implement will determine what happens in the editing case imagined; various answers are possible, perhaps most of which would be classified as conflicting changes by a human who looked at the final result. The pitch for CRDTs is "we won't trouble you with the replication details and will eventually converge all the changes. The tradeoff is that sometimes we'll do the wrong thing."
That tradeoff is fine for some things but not others. There's a reason why git et al require human intervention for merge conflicts.
The article is doing a classic bait-and-switch: start with a motivating example then dodge the original question without pointing out that CRDTs may be a very bad choice for collaborative editing. E.g. maybe it's bad for code and legalese but fine for company-issued blog posts.
I think people who haven't worked on problems like this have much higher expectations than people who have.
If you have worked on problems like this, you're very happy to converge on the same state and have no expectation that multiple concurrent editors will be happy with the result. Or even that one of them will be happy with the result.
You wouldn't use this in a situation like version control where you have to certify a state as being acceptable to one or multiple users.
to add on to that, it is that the resolution is the same regardless of the order in which the nodes get the information that led to the conflict so there is no "out of sync". your resolution strategy could involve considering the potential conflict unresolved until a resolution element is created (but then you have to figure out what to do if you get more than one of those.. its conflicts all the way down!)