[...] All I am doing in my pipeline is XML to XML transformations on a
hierarchy of collections. It is just that at one point in that process
I may want the output to go to two locations. To do this outside of
XSLT I will have to generate a different file that contains the
published file list and then copy the files - introducing unhelpful
latencies and potential points of failure.

If the glue for your series of XSL transformation was a general-purpose
language like Perl (only XSL 1.0, unfortunately) or Java or some .NET
language, there'd be no latency in the sense of process creation overhead.

As for failure to copy, if the disk is full, it is full - regardless of
platform chosen.

Surely the mere fact that results-document exists in XSLT suggests
some elementary file processing may be required.

I think this is mainly intended for generating multiple output
documents, like document() and collection() serve you when you
have multiple input documents.