Considering a ROS application a system where the behaviour is as much determined by the flow of data as it is by the way it is orchestrated is something I think many of us have been doing for a long time, precisely because – as you write – it is a natural way to think about these systems.
I’ve seen quite some applications where ROS is essentially used to physically distribute what is essentially a monolithic program with a traditional (imperative) flow of control over a set of nodes that are all tightly coupled in both time and space by just replacing regular function/method calls with RPC (services). Those typically also include some form of sampling (storing ‘the latest’ msg in a member variable, delagating the processing of data to a separate flow of control), which can lead to synchronisation issues between components and dataflows (the move_base problem with late laser scans is a famous example of this).
Perhaps it would be a good idea to expand the wiki/ROS/patterns page with some actual software patterns. Reactive (or Event Based) systems would seem to be a good candidate.