HTTP-JSON—RPC can do this, though. You don’t need the weird hypermedia or pseudo-OO ideas that are usually implied by “REST”; you just need to POST when you need to POST, GET when you need to GET, and set your headers properly.
Most of the benefit of REST over SOAP was the fact that it used HTTP correctly instead of implementing a redundant protocol on top of it. Having machine-readable API contracts is still extremely valuable; we just found better ways of doing that.
Right. HTTP (i.e. REST sans hypermedia) gets you interoperability.
It doesn't get you the "flexibility" of hypermedia/HATEOS, but it depends on your application if you need that. Most projects don't call for 15+ year APIs.
E.g. you can stick an off-the-shelf caching reverse proxy in front of a server.
E.g. you can split data centers and direct your hypermedia links there.
I think there are often more important things then just interoperability and flexibility, but those were the guiding principals of REST.