I think the variation in the responses is indicative of the lack of a common framework for describing a process, which IMO is itself a symptom of the regrettable lack of formalism and discipline in the practice of process modeling. At the risk of adding more chaos to the mix, here is my take.
The "right-sizing" of something should have some kind of external, objectifying framework by which the quality of "right-size" can be measured. If the process is long and complex but yields a reasonably consistent valued set of outcomes, then how is it not "right-sized" for the process owner or the process customer? Here is where the choice of that framework sees the spectrum of results, from good to bad, based almost entirely on how the framework defines it. In other words, "right-sized" is whatever my methodology says it is, and we can argue forever amongst ourselves as to who's framework for right-sizing is more right! For what it is worth, I like a framework that includes attention to fulfillment of associated goals, to conformance with governing architectures, and to the measurement of effeciency. Since positioning one framework's value over another is what drives the business model for practitioners and vendors alike, I think there is little-to-no hope of consensus here.
The "right-sizing" of something should also have some kind of internal, objectifying framework by which the qaultiy of "right-size" can be measured. And here there is some hope for standardization. In SW design, we have principles of coupling and cohesion that are agnostic with respect to design methodologies and techniques - possibly because they deal with underlying "meta" concepts in SW design that can manifest in all methodologies and techniques. Together, these concepts define the "granularity" of the design construct, and there observable implications among different levels of granularity in SW design and in process design. While the explicit incorporation of these two concepts may sometimes be lacking, the implicit incorporation is often there because they are simply too fundamental to the art and science of SW design, so they are there in the background of the designer's thinking. Process design could learn a lot from this, and we should be able to accumulate data about designs that provide an empirical basis for design parameters, much the same way that SW design metrics (think something like function points) are used to estimate work on SW systems. There HAS been some work in this area (including my own), but the process modeling community needs to step up in acceptance of what it is doing as something serious and meaningful, worthy and in need of formalism, and not just drawing pictures with boxes and arrows. I mean, my young daughter can do that much. What we do should be more than that.