Rich clients built against a REST API tend to need some sort of client-side cache so that clients can avoid repeated RTTs back to the server for data, and thus some sort of websocket-based invalidation system so that the server can push fresh data into that cache in real time. That's doable, but a total bummer for interoperability and shared tooling. Since the implementation of those things is usually custom to each app, it's rare to see one real-time app connected to another the way we can bolt server-based REST apps together. And there's no `curl` for this kind of endpoint.
DDP is actually quite simple. The spec is just a couple pages of markdown. It lets servers publish changing data sets to the client and it implements once-and-only-once remote procedure invocation. It runs over a websocket or over SockJS. Eventually we'll also define a binary TCP/TLS mapping for use between servers.
When you write `Meteor.publish` in a Meteor server, you're defining a real-time DDP endpoint, like a streaming version of GET. The server makes the common cases easy -- publishing a realtime MongoDB query to a client is a one-line function in Meteor -- but you also have access to the low-level DDP messages if you want to do something more advanced like publishing the output of a GPS sensor or a stock ticker.
There aren't any special bindings between Meteor clients and servers, just the standard DDP messages that go back and forth. So you can implement either side of the wire using something else. And there are some third-party implementations of both the client and server in the field now. You can write a Meteor front-end against a Java DDP backend. You can connect a native iPhone app to a Meteor backend. Or you can have two Meteor server processes, one subscribed to the other. (There's been discussion of all these cases on the mailing lists. We use server-to-server DDP heavily in Galaxy, the hosting product we're working on.)
[1] https://github.com/meteor/meteor/blob/devel/packages/livedat...