I don't hear people talk about the design side of services vs libraries enough, but I think it's a huge part of the picture.
Many people reach for services too fast because they feel more comfortable thinking about APIs through the lens of HTTP verbs and resource URLs than they do in the comparatively infinite garden of options inside a program.
The REST paradigm, despite most people not understanding, needing, or utilizing it fully, has out-competed most other software design memes. It was well-positioned to do so, with its creator being an author on the HTTP RFCs and the internet exploding in popularity and use right as the work was published.
REST (and earlier, SOAP) also had good business/network reasons to become very well known: a business who wants you to integrate with them must tell you about their integration pattern. They need to document it and motivate it. Then people have to actually write a lot of software that works that way, over and over. Exposure spreads at the speed of business, and a broad culture of REST-knowledge was inevitable, as was an industry of teaching it. Learning "REST" has long been a compulsory part of learning web-interfacing development.
By contrast, can you name a similarly restrictive organizational zeitgeist for internal program structure?
Domain Driven Design, maybe? The broad concept of "design patterns"? "OO"? None of these are anywhere near prescriptive enough to answer the classic question, "how do I organize this greenfield project from scratch?"
Maybe someone could take a restrictive set of best practices for internal API design, write a dissertation on it, give it a great name (like NICE) and then proselytize it effectively enough to gain mindshare and improve the design options available. (This seems like an interesting marketing problem as much as it is a software design one!)
As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.