I think a lot of these come down to the lack of people with good programming fundamentals. If you understand how to break things up to be maintainable, then when you break things up at _any_ stage, they will always be more maintainable, not less. I think the fear of doing it too early comes from people who haven't worked on well-architected systems. All they've seen is a world where breaking things out just leads to complete cognitive overload, so they see cognitive overload as the inevitable "price" of breaking things out, rather than seeing breaking things out as the way to manage cognitive overload.

One way for developers to become skilled at breaking things out properly is TDD. When the test comes first, by default you're going to come up with extremely simple designs that have well-defined "seams." And the tests then form a vital part of your documentation.

One thing I'm currently learning the hard way is that you can document until you're blue in the face, but if the team doesn't have the mental "hooks" to understand how the pieces they are building fit into the whole, they're not going to get it from just the documentation. They have to see it come together at the end, and in the interim they're going to diverge from the docs toward what their experience tells them to expect.