I think you got this right, but the other thing is also that either of those approaches can work in the small, but they just don't scale. For the engineering side, at some point you need "architects" or people whose sole job is to maintain consistency of the whole system, and one way to break down work into smaller components is to define interfaces between components. This is crucial, throwing more people at a larger problem just doesn't work (in my experience) if you don't have this (and it can be entirely informal... engineering orgs tend to route around beancounters!). So the quality of people, not number or methodology is the main driver of success.