[sarcasmic]

1. Communicating clearly in 'business language' is essential when the junior developer interfaces directly -- not through an intermediary -- with business people and stakeholders. This tends to happen in heavily siloed BigCos, especially in places where IT is just a business unit among many, much more so than in SV or startups. But it's also a skill that one rarely has an opportunity to use in isolation, away from the pressures of estimation, project management, of implicit requirements-gathering by listening to business units segue to different business problem, and sometimes of fudging and obfuscation and make-believe falsehoods to soften the impact of reality. These are complex dynamics usually played at the senior team lead level. Most team leads know this, and don't subject junior engineers to this game with no help.

2. These sorts of high-level expectations tend to get peddled around a lot, not the least bit because it's both noncontroversial advice and a desirable baseline, but they aren't even always necessary. Often, the systems one will work on already exist, they already don't conform to an idealized model because of a series of fixes and mistakes made under pressure. These points are a stand-in for saying you should design and code in a way that future maintainers can make sense of what was written. Sometimes that's using patterns and strategies that are well known, instead of a contrived variation. Sometimes that's staying true to the existing design of the product and the codebase, because tacked-on parts in a different style will increase complexity of the whole.

3. Interfacing in the design and mechanical sense, and achieving that design consensus using interpersonal relations are really two separate skills, and once again it's reasonable to expect that consensus to be set not solely by junior staff between different business units. After all, interfaces and system boundaries ought to have business significance -- not only because of the implications of Conway's law, but also because interfaces and their outputs are often the only orgwide-visible products of the business unit. They must stand up to, or meet the challenge of future pressures such as planned re-use and enhancements, some of which will conflict with the intentions behind the original design.