So, CRDTs are just a tool at the data layer to provide a way to resolve inconsistencies. A simple and easily understood example is an add-only set; in the event there is inconsistency it can be automatically resolved; the consistent state is just the union of the sets.
Now, while that model will give you predictable behavior to resolve inconsistencies, it's still eventually consistent (well, hopefully; CRDTs, being a data structure, also don't enforce that the system actually resolves those inconsistencies, just guarantees that it can do so in a correct way). And it doesn't tell you anything about the rest of the system.
I.e., even using CRDTs, if I have an internal netsplit, if you write to one partition, and read from the other, you will miss data (and if I try to read again, I might read from the partition I wrote to, so some reads return state T, and some reads return state T-1, until the consistency is resolved).
The benefit to CRDTs is that when the consistency is resolved (no guarantees on when that will be, or that the system as a whole ensures it!), I've definitely moved forward in time. Not all conflict resolution mechanisms provide that guarantee. For instance, Cassandra's (which came out of Facebook) old default (maybe current, I haven't used it in a while) of "Last Write Wins" meant that clock drift could lead to weirdness. I.e., at my time T I write X = 1. At my time T+1 I write X = 2. HOWEVER, the clock providing the timestamp of the change for the second is lagging, and thinks it's actually T-1. When the system deconflicts, T > T-1, so X will remain equal to 1, even though from a true temporal sense I know that X should be equal to 2.