Q1

True. But for the most part it doesn't make sense from a standpoint of clarity and natural language. Let's say you have model Product and you want a service object that will handle pricing on some complex criteria (geolocation, color, shipping, moonphase, etc). It would be a good candidate for a service object ProductPricingService. You wouldn't just call it Price or Pricing. First of all it's ambigious. Pricing of what? Products that you sell? Pricing you get from vendors? Pricing of gas today? And if you were to argue that this Service object could be used by many models, then you are defeating the purpose of Service Object. I'm exaggerating of course. But the whole point is to create clear and maintainable code. So while you can save some keystrokes by naming it Price, it's much more clear to another person ( and you in 5 months) if you name it ProductPricingService.

Q2

For instance let's say you have model Product. you have methods like :

If this is the only method that deals with labels you have and it's that simple than creating a Service object is an overkill. However if your method becomes complex or you find that you need multiple method for related things: