1) Test driven development. Before=as=so-soon-after-that-noone-notices you make some software, you make a test for it. If the document has a fixed structure, you can test by instances. If the document is semi-structured or recursive, your test specification has to allow those kinds of structures too: and for XML such a specification is called a schema.
2) Quality assurance. I work in a company with a globally distributed development and production system: (it is so big that US content architects may forget they have brother content architects in other countries when casually posting :-).
3) Conway's Law. A successful system must have sub-system boundaries that match the organization. Formalizing a boundary that matches internal organizational boundaries helps reduce communication costs. Formalizing a boundary within a team needs to allow flexibility, agility, otherwise it will get in the way.
Where I would disagree with Simon, I think, is that I think the advent of JSON for point-to-point interchange actually means that probably you should always use a schema with XML: if you don't need a schema perhaps you should be using JSON?
Actually, that is too much: what trumps often is how easy a format is to fit into your current ecosystem and capabilities: