This morning I was pleasantly surprised when I found that Bruce Silver in his book "BPMN method & style" advocates exactly the same thought. Judge for yourself, which diagram is clearer:
Another reason is that having the possible results clearly labeled, the different labels gives your reader a first check wether your process description is complete or not.
The 2nd representation may be more correct from a theoretical point of view. In the second diagram, we have an End Event which actually represents an End Event. In the first diagram, the End Event represents more an End State than an End Event. Still, the BPMN 2.0 explicitly states: "There MAY be multiple End Events within a single level of a Process.". So when possible, I prefer the representation which gives the highest amount of clarity.
Some loose thoughts on end events:
- In the above illustration, both diagrams have the end results on the right, which is good. It makes a diagram easier to glance over. Some people do not start reading at the start, but start reading with the result in mind.
- I often see End Events labeled as "End" or "End Event". Usually these labels are the result of sheer laziness, though occasionally they result from insufficient knowledge of the tool or lack of time. And to be honest: I am guilty of the latter. Do take the slight amount of time to label your Start Events and End Events properly. It will please your readers.
- The use of multiple End Events may be discouraged in some simulation tools, where the consumation of a token generated by a Start Event stops the entire instance. Any such implementation is i.m.h.o. against the BPMN intention: the process should run untill all tokens (the token from the start event may have been duplicated in a Parallel Gateway) have been consumed.