Motivation
We want to prevent service rot, duplication and loose coupled services, in other words good building blocks
Argumentation
If a service does more than one thing, it will likely not do everything well. The success ratio of a service correlates nicely with the characteristics of reusable code, namely code which does one thing, and one thing well 
Use the service layers to decompose the service and place the parts into the correct layers: see The Laws of SOA paragraph 2.
Exceptions/special cases
Typical misunderstood attempt on an exception:
In some cases you may have to violate this principle for performance reason.
However, the service is probably designed incorrect if this is the case.
Arguments:
- If you violate this rule, your service will not be re-usable
- If you violate this rule, your service will duplicate business logic and will be life-cycle dependent on all the services which share data and behavior
- Exposed data from such services will be incompatible with data from all other services
- The quick-win scalability argument is better solved with collaborating instances of data-providing services (shared state backbones, eventing backbones and similar state-sharing techniques)
- See Service governance quiz for detailed discussion.
Definitions
Status
PAB discussions
Can a H2A service to too little? We should add a new checklist item which ensures that we provide enough business value..
Design-Time Governance - SOA Design Rules FAQ
- [Question still to be asked..]