I can't think of a single more successful achievement of software engineering, so can someone explain why I shouldn't answer with an emphatic, "yes!" to this question?
I get the web has all kinds of flaws, and maybe we can do better, but as far as I know, we haven't even come close to actually building something as useful or ubiquitous or stable as the web.
I've been using redis pipes (and databases in general) to get services to talk to one another, and that has its uses, but why must I do that or do REST? Why can't there be a place for both?
Because you've taken a single question from TFA out of context as a straw-man. Yes, the web has been enormously successful. But that's simply irrelevant to the practical questions posed by the author. To stitch together the full question that Ben Morris is really posing using a quote from the article:
Is the web a model we really want to emulate [as] "the only collaboration fabric for a large and complex set of decoupled, autonomous and collaborating services"?
To which I could just as emphatically quip "no!" Note the "only" in there. Morris is explicitly not throwing REST out, but questioning the REST-uber-alles mindset by pointing out limitations of that paradigm.
Immediately after the quote you pulled comes (IMO) the best part of the article:
It’s not just HTTP that provides a limited model for service integration. The web has been an inspiration for REST but is it really that successful a distributed system? It’s slow, fragile and prone to security problems. It’s vast, decentralised nature makes it impossible to find anything useful without indexing engines that are so vast that only one or two companies have been able to create them.
It's not, again, that the web isn't successful. It's that the applicability of solution to problem is being questioned.
To me REST in enterprise is simply reflective of how broken SOAP and XML-RPC was in practice in enterprises and made for far too inflexible, monolithic services that'd take years to move forward major versions. You can decompose REST respurce URLs at least and try to scale out from there instead of being stuck to the service definition's XML schema for every resource definition. Sure, I've seen some Schemas that are composed but in the world of enterprise software vendors and internal bureaucratic services you will devolve to the pathological cases of simplicity in your architecture to get the bare minimum done, and REST works better in practice here than anything WS standards related.