Yes, because when exporting to STEP, OpenCascade will retrace the hierarchy top-down, while the order of labels in the XDE document is nothing but the persistence order. These tags are pretty much like GUIDs of unique records in a database, so the label's tag is quite meaningless here.
The size of a project is not an issue as long as you have enough memory and it does not slow down other modules of your software (e.g., visualization and UI). Whichever means you use for composing a document, you have to end up with a structure that does not violate XDE rules. As for assemblies, there are always two levels of hierarchy. The top-level labels inside an assembly "folder" represent "prorotypes", i.e., parts or subassemblies that are to be linked together as components (the second level of a hierarchy). This top level is referred to as "declaration level" in the figure below:
View attachment 481
The second level of this hierarchy is designed to represent components, i.e., lightweight links to other entities from the top level:
View attachment 482
The hierarchy does not go any deeper, because, from a component level, you're supposed to jump to another top-level label using the provided TreeNode link. There's actually one exception from this rule, where you might have the 3-rd level entities to represent subshapes under parts. Such sublabels are used to assign colors and other metadata to subshapes.
All in all, when composing an XDE document, you need to be sure that these nesting rules are satisfied, and then it does not matter which tools or API you're using. To have a shape under a label, you need to have `TNaming_NamedShape` attribute. It's allocation is done by `TNaming_Builder` tool like this:
Code:
TNaming_Builder NB(yourLabel);
NB.Generated(yourShape);