If you take the time to read the wall-of-text you'll find out that it's based on pub/sub and not RPC-esque like Meteor (which he also acknowledges in his wall-of-text). New? Probably not. Valuable? Not sure, pubsub is expensive but when you need it you really need it.

Well observed. The problem with client to server RPC is that it's difficult to scale horizontally. When using pub/sub, on the other hand, you are giving control to your data consumers (frontend clients) so you don't run into issues of having to get references to specific users from your server (what if that user is connected to a different process/machine and not the current process?). I did a presentation a few weeks ago at my local JS meetup group which explained the issue better: http://slides.com/grosjona/realtime#/

I'm not sure about the details of Meteor's RPC implementation so I can't comment on it specifically.

Meteor's DDP protocol is both pub/sub and RPC.

Doesn't Meteor implement pub/sub using DDP?

DDP does sound similar to pub/sub. Maybe it's derived from it? Another approach for sharing realtime data between multiple client/frontends is via operational transform or differential synchronization but that is very expensive and it appears difficult to scale beyond a certain point due to latency (good for collaborative editing of rich text documents, but I'm haven't heard of it being used in other contexts).

I wouldn't say operational transform is an alternative to pub/sub. The two could be used together.