Thanks a lot for answering.
"the issue of the highly heterogeneous environment with many (I read between the lines as probably "siloed"?) teams begins at the organisation structural level."
This is very true. Unfortunately, infrastructure teams don't have the ability to change that structure. I would, in fact, guess that a lot of the consulting work in the infrastructure-as-code sector exists, because ABC company started building their code base from two "lazy" technicians that wanted to automate their work. Now, everyone hops on board and their code sucks, because it didn't scale, and it needs to get cleaned up. Infrastructure-as-code (I'm guessing for most organizations) doesn't start at the organization level, so you deal with what you have.
That said, a lot of organizations don't dictate the applications that will exist on their infrastructure, i.e. the public sector. If a town, state, government, school system, or health care system choose application Foo, Bar, and Beef to use as their new applications and Foo has a Lamp stack, Bar is a .Net application and Beef is a Client/Database system with an Informix backend, nobody cares that you have more knowledge about Linux or Windows or Oracle or MSSQL. You have to deliver those systems. And for large organizations that requires a very diverse set of applications that need to be configured and handled by a lot of people. Here lies the rub. A lot of people doing small changes consistently.
I think sub-modules might actually be the answer. I also read from this blog entry, in the comments, by Gary Larizza, http://garylarizza.com/blog/2014/02/1..., that he's seen people simply invert the module name and the sub-class "profile" and then check that in and allow that team to handle the configuration.
You're right that you don't want a lot of repetitive shit lying around, creating a murky, confusing code-base. On the flip side, these are the wrappers (the roles and profiles). Those writing a profile don't get the option to screw up all of the architect's hard work; they only get to slice and dice what's given to them, i.e. the modules that are created and imported for the organization.
I'll try and do a write-up about our successes and failures when it's done and re-post my findings here for future reference.