question

The most obvious is that you can represent processes using process flows without the need to define them in tables and have coordination code interpret the process from those tables. A process token (or multiples thereof) will store the state of an invocation of that process which prevents you needing to write tracking logic to store states in the 3D or table sections of the model - the token locations themselves and any labels they have can be enough.

Process flows can also be used to model behaviours of machines or cells where that behaviour is complex and has interdependencies that might only be associated with one 'top-level' process step. Adding all that detail to a 'top-level' process definition could be too cumbersome and might need to change depending on the cell/machine to which a process step is assigned. If you use an object flow for a machine/cell process definition, any members of that flow can have the same behaviour without any further updates - there's only one flow definition for them all - this can save managing objects (although that is now easier using object templates but they are not perfect).

An object flow can be associated with a container (eg. cell or composite machine) and can use pointer labels to reference the objects within it to make the defined activities 'instance friendly' where no additional modelling or data structures are needed to create new instances of the cell/machine or to place them into a user library for use in other models.

Within emulation context having your emulation variables in an object process flow allows you to use the instance specifier to refer to PLC tag instances that relate to the process flow instances - probably the best way to scale you model in this context.

Having a process defined using process flows allows you to listen to events of the activities using Statistics Collectors. This allow you to capture milestone events and triggers using the state changes of the process invocation (transitions between activities).

Process flows also benefit from having a number of event triggering activities which mean that you can easily set up listeners to parts of the model that would be trickier to achieve in code and would not be as easily managed.

You may also find that the task of verifying and validating the model, especially with 3rd parties, is simpler when you have processes and behaviours represented in process flows.

I'm sure there are other benefits I've missed.