So: I was the other side of the email conversation that Moxie alludes to in this post, so I'll respond to it here given comments are disabled on the OWS blog :)
1. Totally agreed that federation slows down evolution of the core protocol. However, higher level protocols do NOT have to be stuck in time forever in the manner of SMTP if you design them with a migration/evolution strategy from the outset. For instance, with Matrix.org the core premise is decentralising communication between different networks. This includes different versions of Matrix itself. We could build an entirely new Matrix 2.0 tomorrow, using (say) a fully p2p WebRTC Datachannel transport or IPFS or whatever rather than today's HTTP APIs... and simply bridge it into the existing Matrix network using Matrix's existing bridging architecture. In fact, one of our favourite thought experiments is the process of how to evolve Matrix into a full e2e-and-metadata-privacy-protecting protocol at some point in future - as per http://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20En.... How you protect metadata privacy if locked to a single centralised service like Signal is perhaps questionable.
We believe that avoiding being dependent on any single communication provider is just as important to user freedom as maintaining communication privacy. If I don't trust Signal to host my communication reliably, I want to pick my own provider... whilst still being able to talk to other Signal users.
One could argue that end-to-end encryption is incompatible with federation, as if a vulnerability is found in the encryption ratchet you need the power to upgrade the world 'instantly', as WhatsApp or whoever can. However, I am not convinced this is a showstopper. It's certainly convenient that WhatsApp can instantly lock out all versions of an app which are known to contain a vulnerability from their network, but you can get a similar effect by issuing a press release as per heardbleed, poodle etc; giving users a way to check if they're vulnerable; encouraging them to move to a provider or app which is not vulnerable. It's not watertight, but it's a compromise I think many would be willing to make in exchange for having the freedom to select their communication provider and communicate with who they choose.
2. If the federated protocol has well-defined layers, it's not even a problem if the lower layers are slow and hard to evolve; you just go and swap out the higher layer ones. Internet Protocol is so widely deployed it's infamously painful to evolve... but it's a relatively simple and well-focused problem domain, so a huge migration like ipv4->ipv6 happens very rarely. But it hasn't materially slowed down the adoption and uptake of the internet - in fact, ipv4 is a victim of its own success! Meanwhile, HTTP is also so widely deployed that it's a relatively slow process to do something like HTTP/1.x->HTTP/2. But, again, it turns out this isn't remotely a showstopping problem - most of the interesting stuff happens layered as applications on top of HTTP - HTTP does one thing, and does it relatively well, so it's a great building block. And it's the basis of the entirely open and interoperable architecture of the web.
With Matrix, we're trying to provide a similarly simple and focused base layer: a decentralised pubsub/storage API layered on HTTP. We provide some modules that define additional semantics (messaging, VoIP etc) as layers on top of that core API (http://matrix.org/docs/spec/client_server/r0.1.0.html#module...) which can evolve separately.
We believe that having an open and interoperable protocol for securely synchronising data in realtime is as fundamental as the web itself, and this is NOT a function that should be silo'd into any provider.
3. The blog post says: "One of the controversial things we did with Signal early on was to build it as an unfederated service.". This seems a bit strange, given the TextSecure server itself exposes a basic federation API: https://github.com/WhisperSystems/TextSecure-Server/tree/mas...
4. My actual retort wasn't to tell Moxie that he's dumb - he's obviously an incredibly smart guy, even if I disagree with his position here. I actually said: "Okay. The internet wouldn't have got very far without interoperable application-layer protocols defined by 3rd parties, but if you would only ever consider using one for TextSecure that you invented yourself, that's your call :)"
So, if anyone's reading this and still believes in the dream of an interoperable and federated internet, feel free to come hang out at https://matrix.to/#/#matrix:matrix.org and live the dream :)