> However, if you actually spend time to work out a process and organization that will not require additional each-to-each communication and make most of the communication remain in close groups, you may avert this. You can call this a human refactoring, if you will - very similar idea to separate functionality into small, encapsulated classes with smalles possible public interface instead of one huge g-d class.

I dont think this is an exception to my rule; you can reduce the overhead significantly with good process, but any process that does not perfectly predict who needs to know what information will incur some per-person overhead as a team grows.

Perhaps you are arguing that this overhead can be reduced to the point of being close enough to zero to not matter? If so, that would be very impressive, and conflicts with my experience.