Simplicity is good, but so is flexibility and compatibility. As I mentioned, parts of REST aren't good enough; anything that doesn't have access to http status codes won't be fully compatible. A decent RPC protocol like JSON-RPC is both flexible and simple.
An added bonus to not marrying your protocol to http is that your API will work seamlessly over other protocols should the need arise. I have an API that was originally intended for web clients, but later the need arose for some internal tools to be able to call the same methods remotely and asyncronously. Instead of going over http, the jobs are submitted to gearman in JSON-RPC format and everything works without having to modify the server or unnecessarily and inefficiently route the calls externally through apache.
I used to argue in favor of json-rpc as well, but I have to say that I have allied with the dark side now. if for no other reason than caching, with REST you have fine control over what addressable resources get cached and which do not. This is huge for performance in some systems. I have found once you use REST semantics in earnest to build an application, it is hard to levy argument against it. So much of the webs infrastructure starts to work with you and not against you once you start to use it.
It's possible my perspective is skewed. I write APIs for stateful applications, so clients don't ask for the same information over and over, reducing the need/utility of browser caching. I can see how REST would help solve the caching problem.
I agree with that. But here you aren't talking about HTTP you are talking about RPC. You could have gone with RPC directly from the very beginning. Typically, you put that on top of HTTP to avoid firewalls, etc.
I said simple as possible, but the real world is always complex and one day you may have to use something other than JSON-RPC in which case someone will have to create an adapter or an abstraction. Thankfully this is easy to do in software even if it sometimes looks nightmarish.
