To me, it's an issue of trade-offs. Standardization, which I think is at the root of Simon's comments, is efficient - you in effect create a single set of designs, making it possible to custom manufacture parts or pieces in parallel for many different projects simultaneously. What you lose with that efficiency is flexibilty - the ability to move outside of the standard, to add embellishments on the design to fit specific needs. This is true of data modeling regardless of whether you're talking about UML, XSD or (to an extent) OWL.
In theory, the RDF open world assumption mitigates this somewhat; you define the behavior of a model for those cases where you need specificity, but unless you specifically disallow it you do not implicitly disallow non-standard relationships - the analogy of customization or ornamentation. Of course, the downside to this is that the non-standard components do not then have rules specifying their behavior, because they are, by definition, outside of the schematic model being created. In practice, what this usually means is that your schema makes an assumption that those parts that are not defined within that schema will be defined at some point by some other schema. This corresponds (roughly) to xsd:any with lax validation.
Of course, I've seen way too many XSD schemas that were designed in such a way as to not allow for this escape hatch, and indeed, a lot of tools that utilize XSD schemas - such as JAXB for Java object serialization of schemas - go positively crazy in the presence of xsd:any. That has to do more with the fact that most people do not understand validation or data modeling with a hatch for flexibility than it does with tools. They see validation as binary (something is or is not valid) rather than contextual (something is this valid in that context). This becomes more evident when you create contextual bindings (such as XSD 1.1 or Schematron), but neither has achieved the degree of awareness that XSD has, principally because XSD 1.0 is so inextricably bound up with WSDL.
