1. Splitting data into separate files (e.g. separate IS, IL, TT, RS files). With global elements these files can start at their domain element, with a separate file starting at <railML> referencing them all by UUID. Without global elements, each file must start at <railML>, but nothing else changes.
2. Sending an update for one specific object as a snippet. With global elements + UUIDs it is possible to create a valid file containing just the desired object(s). Without global elements this must be handled via methods outside of railML (e.g. diff files in version control systems).

From my point of view, the greater flexibility in reusing the schema and the fact that railML3 apparently already follows the pattern "Garden of Eden" more than "Venetian Blind" (in contrast to railML2.x) speak in favor of a consequnt adaptation of railML3 to the design pattern "Garden of Eden".

The (subjectively) better comprehensibility of the "Venetian Blind" pattern speaks against this. In addition, as a developer of railML interface software, I do not (yet) see any need for the transfer of subsets of the railML schema, all our current applications are based on the transfer of complete railML files.