Remote Procedure Calls
Frequently PSYC is seen as an RPC protocol. That is inaccurate in the way PSYC defines a lot more functionality than that, which especially in the case of multicast affects the flow operations in a way RPC is not expected to. That doesn't mean that couldn't be quite a useful innovation. By defining your own methods and variables within the PSYC syntax, you can employ PSYC as an RPC protocol.
Seen in comparison with other heterogeneous interserver protocols, PSYC is sufficiently lightweight and easy to parse. A lot easier than XML-RPC or SOAP for example, two notable HTTP abuses. Doing RPC with XMPP is a bit better, as you don't abuse HTTP for transport, but still you have the heavy XML parsing.
Real RPC protocols are frequently binary and typically need all distributed nodes to operate under a common administration policy. In exchange they can be more efficient than any of the plaintext-based protocols. Erlang is an application framework and programming language that has such a built-in asynchronous binary RPC protocol, which looks quite efficient. The strength of this is the obvious utility in not having to parse pretty much any syntax at all. The weakness is, you can hardly have a decentralized network of heterogeneous applications all agree on such a protocol. Once you do, you need to pass method names symbolically (by name rather than by numbering them), and that's the point where you start re-inventing a multi-purpose protocol such as PSYC.
PSYC's strength as an RPC protocol must lie in the simplification you get when you also need many of the other features of PSYC, without having to use a completely different protocol syntax and API. PSYC won't do super spectacular fast, but it gives you a single consistent framework to operate in. In fact, at the time of design, future MMORPGs were also considered as a possible application for it.
Jabber can be operated in a similar fashion, but the way how the Erlang RPC protocol is such a success in combination with XMPP tells something about it: it is really much more efficient to avoid XMPP within internal communications, and have something native and quick instead.