Martin Fowler has a blog entry in which he publishes a rough-and-ready list of enterprise software practices, along with the number of positive and negative points a group of conference attendees assigned them.
He doesn't make any effort to rank the practices, but I do. There were four uncontroversially detested practices, listed here by adjusted score (positive points - negative points):
|-21||1||22||Separate development teams by layer.|
|-18||0||18||Distribute at layer boundaries|
|-15||0||15||Rethrow exceptions at layer boundaries.|
|-7||0||7||Layers should have separate deployment units (eg separate jars or assemblies for each layer).|
The first thing to leap out at you, that every single one of these is about layers, turns out not to be significant: 90% of the original list is about layers; it's kind of a preoccupation (or maybe an obsession) with enterprise guys.
But scratch a little deeper and you strike gold: three of them are about overloading the meaning of layer boundaries with additional significance: places to chop up the team, the runtimes, and the deployment units. Since these principles have been so roundly rejected, we can conclude that this group considers layer boundaries orthogonal to team, execution location, and deployment unit boundaries.
I still think "Don't get involved in a land war in Asia" should have been in there somewhere....