I think the debate about using UML v. other notations or methods should be considered from the point of view of what is the purpose and objectives of your modelling. If you are developing process models for a process improvement type initiative, where diagrams need to be shared and reviewed by a large audience of non-technical business users, then UML, in my experience, is probably not the right approach.
UML is an excellent approach when it comes to systems / software engineering, system architecture design and requirements management; but not as a method for sharing and communicating business process models across the organisation.
A more easy to understand notation will be much more effective, and it seems that BPMN has now become a well established approach for this purpose. Additionally, I think that the fact that the OMG chose to develop the BPMN standard in addition to UML speaks for itself (as you may know, the Object Management Group - OMG, is responsible for the development of both standards). Therefore, in my opinion the approach offered in the book is more suitable for technical analysts not for people running a business focused process modelling initiative.
However, I do agree with the author's key point about the fact that in order to fully understand the process complexities there is a need to document more then just the process flow (conduct a 360 modelling, but which comes more under the domain of Enterprise Architecture not purely process modelling).
Furthermore, various process modelling tools today do offer the ability to easily capture many additional dimensions then just simple flow diagrams. I found the approach advocated by Ian Gotts in his book "Common Approach, Uncommon results" highly effective for getting organisations to document their processes and gain the benefits from doing so.