And because there are decades of best-practices and standard ways to do very common things like authentication, caching, signaling errors, load-balancing, logging. Maybe a homemade RPC doesn't need any of that, but I would bet that at some point it will need at least some of it. And now you have to implement it all yourself.
This is cool though and kinda fun to think about!
Essentially either you want RPC, or you might want caching. If you want to put a varnish cache in there, probably stick with http. If you know you're doing (very high thro / low latency) RPC - this might make a lot of sense.
So it's not so much if you want to memorize (cache), but if you can* (and/or should).
I'm afraid I'm repeating myself - but I really whish people would read all of Fielding's thesis - it's got all kinds of reasonable architectures in it - even if it argues hypermedia/hypertext applications are well served by REST.
I’m showing that it is just as easy to use a different protocol than HTTP.
Instead of reaching for an HTTP framework to do RPC, I’m showing that Redis can be just as easy.