Your benefit no. 5 reminds me of the transaction concept in database systems: A database transaction, by definition, must be atomic, consistent, isolated and durable.

BAs can and should be asked to think in terms of encapsulation or less technically “all or nothing” to make systems easier to design and less prone to patchwork from change requests.

Your observation that “In its collapsed representation, a subprocess describes the inputs and outputs of the service …” is not entirely correct given that one thing a BPMN diagram doesn’t show is data-flows.

Data (ie inputs and outputs) available to a sub-process might be inferred by the observer and in fact might be defined in sub-process/task attributes, but they are not explicit in a BPMN diagram.

Adding annotations to flow lines is one way of providing this information on a model, but that is somewhat redundant if data definitions are also recorded in process attributes.