A technology reason to have services is that you can have large RAM/SSD caches on services and move that data off of your front end monoliths, shrinking the footprint of the monolith and keeping more data accessible quickly (although small caches for the very hottest data might be good to retain on the first tier). That data probably shouldn't be peeled off though until there's a software team there to maintain the new service, and it should really be living in its own data pool on the backend (you shouldn't be writing a service to front a single database table, you should be writing a service to front an entire database). If the data is large enough and important enough to be moved to a service, and there's performance wins by doing so, and if there's a team that can manage that service, then it probably is a good idea. A single team that is managing a monolith busting it up into a dozen services that they still manage, and all the data comes out of a single database server is probably the wrong way to do it.

There might be some other cases where you have hard business requirements and such for some software to be able to ship without other software and need to build clean lines and services so features can be extracted and probably some other edge cases, but the larger point should be that extracting the service should almost be demanded, both technologically and organizationally. If you have a choice and it isn't clear, then a service is probably the wrong thing. Services also really shouldn't be "micro" until you're an absolutely huge company and you can burn entire teams on small edge cases.