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: