During the time I worked for Amazon, the entire Amazon infrastructure was written as services. It indeed felt like a bucket of cold water in my first month at Amazon, especially after having worked in software products company for 10 years prior to that.
But gradually, I got used to the services based architecture, where something as simple as presenting a login page would lead to dozens of REST API calls back and forth between various backend services.
I am not saying that one approach is better than another. I would have to dedicate a separate comment to discuss that. All I am saying is that developing an entire software system composed purely of generic services with HTTP based REST APIs indeed exist and are very successful in very successful companies.
Absolutely. At Amazon's scale, the justification is there. Things are different for invididual developers and small teams where the mesh of services will be maintained by the same people anyway.
If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you're dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It's a huge tradeoff that requires serious justification.
Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
There's a reason why we're not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)