This completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.
> it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names
It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense.
Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing.
Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
