I am using the xmllint tool to check some XML files against their XSD schemas. It would appear that the tool is invoked as
xmllint --noout --schema foo.xsd bar.xml
... and does not include an option to retrieve the XSD file from the XML file's xsi:schemaLocation attribute. Moreover, in the relevant w3.org specs one reads:
The presence of these hints [i.e. the xsi:schemaLocation ] does not require the processor to obtain or use the cited schema documents, and the processor is free to use other schemas obtained by any suitable means, or to use no schema at all.
So is it fair to say that in practice the xsi:schemaLocation attribute amounts to (soft) documentation? Moreover since it is likely not a good practice to allow incoming XML documents to tell the application how to validate them I don't see the benefit.
XSD location hints, schemaLocation and noNamespaceSchemaLocation, are rarely used in production environments (I've never seen it), indeed.
I personally see it as a convenience method for tooling used during development phases. It is considered an interoperable way to indicate what XSDs should be used for validation, IntelliSense, etc.
Say you build a bunch of XML files (samples), as means to better illustrate (document) another bunch of XSD files. From what I am used to see, people use schema location hints (relative URIs), zip the whole set (XSD, XML, etc.) and then ship the archive to consumers. This way, there are more chances to be "interoperable" regardless of what development tools people are using. For example, MS Visual Studio maintains an internal and proprietary storage which holds what schemas go with a particular XML file; that "metadata" is not portable to other tools the same way xsi schema location hints are.
I've also seen some really "advanced" uses of the schema location hints, which is why at least in our tooling we do spend lots of cycles in reading these hints and dynamically adjust the intellisense and validation messages...