Messaging is just degenerate RPC?

I hate to use expletives to describe this guy's writeup since he's done a remarkable job with the cajo project. But I couldn't help laugh at this claim of his:
"Messaging is degenerate RPC: If you want messaging, by all means, go for it! It is a very useful technique. However, it must be seen for what it is; degenerate synchronous RPC: i.e. a tiny subset of the functionality that is possible with distributed objects."

It's good to be passionate about the remote invocation approach that your project uses, but its plain daftness to make silly claims like "this is the right way of implementing a distributed system". For the same reason, I won't pass a judgement. I'll let you consider a few points and arrive at a conclusion for yourself:

1)Could google's apps have scaled with synchronous RPCs?
2)What's better for a high perf distributed system - blocking on a synchronous RPC call or continuing processing until the response to a remote message interrupts you on another thread?
3)In a supply-chain kinda web app, once you receive order confirmations, do you make RPC calls to place orders for shipping each component, or simply queue up the request in a message queue (which a "down-stream" app could just read off and dispatch orders)?
4)Ever heard of "decoupling" applications?
5)What's easier - a 1:n messagetopic (in JMS) or a similar rpc invocation on 'n' remote objects?

I could give you a zillion more examples like this where async messaging scales much better. And "what if the underlying implementation uses rpc's" or "email is just rpc" are very lame refrains: you're generalizing an implementation approach adopted by a messaging system used by humans and extending it to apply to those used by fast applications relying on asynchronous messaging. How're you so sure that the 2 must be implemente similarly?