Not the OP. However, in my experience, the "tax" of communication is that everything has winners and losers. You can state that the "1+1=2" or "the sky is blue" and someone will lose politically. You have to prepare yourself to defend your position even if 19 out of 20 agree with you; because the one person who disagrees with you has the most to lose.
Pretalking is highly valuable. Making sure that key stakeholders have an aligned vision and are invested in defending it before opening up a discussion (or dictate, depending on the culture) to a wider audience is necessary. Occasionally expect that the stakeholders and you got it wrong and you'll need to invest time into rebuilding the solution, but, if you're honest with yourselves and diligent, assume that generally the expert subgroup will supply a comprehensive solution.
The last one is about involving less people. You don't have to read it as "shut up and keep your thoughts for yourself". I read it more like "Do we really need to have six people working on this feature/present in this call?"
I strongly prefer the phrasing of "When do we actually need to have six people involved on this?" It's often valuable to set a momentum and prune obviously poor decision branches before bringing proposals to a wider audience.
> Communication is a tax that you should justify before paying it.
I thought it meant like keep things as local as possible. Like within the same process, within the same machine, avoid going through the network because staying on the processor is always the fastest, going to ram is next fastest, and if you need to communicate across the network it is always slowest
I don't think performance advice should be part of a general architectural principles list, so I don't think that's what they meant. Otherwise might as well add "avoid nested loops", etc, and then it devolves into a general programming advice list.
Performance is and always was something dependent on the domain rules. You don't start architecting for performance before understanding requirements so why make it a pillar of all architecture.
Just one more alternative interpretation… I thought it’s about systems calling into other systems, making everything slower, more complicated and brittle…
But maybe it’s about discussing an issue with 10 other people from different teams when it’s not necessary.
But we will never now. I guess OP didn’t want to pay the communication tax on expressing this idea clearly :)