Interesting. Can you elaborate on this? I am not sure what "inconsistent replication" means.
tcp itself is a reliable transport over unreliable media. So running tcp on top of tcp means running two sets of algorithms for reliability, ultimately doing more work than is needed. Running tcp over udp (where udp is unreliable) means you still get the reliability over the tcp overlay, but don't need to be worried about the udp layer since it can fail and the tcp overlay algorithms will fix up the data stream.
"Consistent replication" would be using a protocol like Paxos to have the replicas decide on a single order of operations.
Which is almost always the case. Except of course, if you build your data as a growing "collection of knowledge", where the order of facts doesn't matter. But this is cheating, since you're implicitly bolting an ordering-mechanism on top of the system in this case.
The other interesting conclusion is that there are other workloads like this. For example, it is possible to build a reliable and better performing lock server in this way as well (and there is an implementation in the github repo). So, you'd get something similar to Chubby, but where the latency to the server is only a single round-trip in the common case.