Author here: a few people have raised this point. Perhaps I should have made a distinction between "federated within the same data center" and "federated across the internet." They are two entirely different problems.
Right, but since Twitter manages all of Twitter's servers (and the dedicated low-latency network via which they're presumably all connected) they can satisfy both of these constraints without sacrificing the third (immediacy). I'm speculating here, but I think that's why it takes a few seconds to post a tweet: it's propagating across the internal federation so that all the nodes have it before it "goes live."
To be specific, your tweet is not timestamped when you send it. It only gets an "official" timestamp when twitter decides to give it one, after receiving it. That means Twitter arbitrarily sets the timestamp whenever they get around to shoving it on top of your feed. So they do have the problem of tweets arriving out of order (due to network latency etc), they just hide it by rewriting timestamps!
eta: I admit this is a smaller problem for a centralized service than a federated one, but I would argue that it can work "well enough".
Except that twitter does go down, so if you had a distributed car that was incapable of hitting a tree it would be an advantage.
The situ with email is that at any moment the system is up but individual nodes may be unreachable or delayed, conversely if twitter is up all nodes are reachable in constant time, but if it's down all nodes are unreachable.
In real systems these two properties are mean virtually the same thing, at any given point in time your party may or may not be reachable with a given latency.
