Jim's points are well taken. If you don't need to differentiate between the flow types, it is likely that you don't need to see a visual difference (at least at this level of abstraction). When you do need to see the difference, the object nodes are there to make this evident; they can also carry additional information that the model can display or query.
Outside of the systems world, I was using EA to model some business processes a while ago (v. 4.1). We needed some means of quickly and simply conveying our understanding of processes to a management community while the processes being finalized. This would allow corrections in the processes as well as helping determine which parts of the processes could be supported by automation. The business processes were unique, involving negotiation between several parties towards a positive end, where previous dealings tended to be settled through legislation and the courts.
By using activity diagrams like flow charts we were able to illustrate the overall processes. Our clients could quickly make sense of things and identify errors. So far so good, and down to the next level. We used swim lanes to show the 'who' dimension and let the activities talk about the 'what.'
By adding object flows we could differentiate between "then we do..." events (the control flows) and "the initialled draft goes to..." transitions (the object flows). The clients, who had no experience with UML were able to quickly pick this up. We initially included notes tied to the object nodes to explain what was happening. Before we could provide a short document to explain the notation they suggested that we remove the notes and forego the help document, as they felt they could clearly see what was happening and understand what was going where (object flow), as well as see the flow of activity supporting the protocols and negotiations (control flow). [Interesting enough, with early experiments using dotted arrows the users complained that the different visual cues were confusing; they were reluctant to continue with that experiment even with a user guide.]
Worked like a charm, even outside of the systems world. When the level of abstraction was low enough that people needed to see the difference the notation is effective. At a higher level it probably won't matter.
Of course these days we might well use BPMN. That was not an option with EA back then. However, my feeling is that at the level of abstraction we were talking about, UML activitiy diagrams did an excellent job, particularly by separating control and object flows. I also think we'd still be giving courses on pi calculus to managers, executives and lawyers to explain how to read the BPMN models, probably using UML activity diagrams as props.
