@DanB Historically, XDE was developed as a data structure that would allow for holding colors, names, and assembly structure after importing all this from a STEP file. Because OpenCascade's shapes are not capable of holding metadata, OCAF was a natural choice. I don't want to disappoint you, but that's actually it. There's nothing more behind OCAF/XDE. If you wish, you might want to develop your own alternative data structures for exactly the same purpose. For example, people often use databases for representing product hierarchies and attaching whatever metadata to parts and instances. One particularly good choice is maybe SQLite (used in Shapr3D, for example). Something like MongoDB might also serve you well.
Nowadays, XDE has become a standard de-facto data structure for all data translators developed by OCC company, including their commercial addons (XT, SAT, DXF). Also, CAD Exchanger software being developed by a former project manager of OCC (now CADEX company) is XDE-aware and it nicely integrates with OpenCascade through this data structure. But, again, this is
just a data structure. To be more specific, it's a Hierarchical Assembly Graph.
Regarding performance, it all comes down to the typical performance issues of C++. E.g., allocating new OCAF attributes is essentially a heap memory allocation that might be costly if used thousands of times. Data access could also be a hotspot if you tend to search for labels by their IDs intensively. If you want to see XDE in action, you might wanna check CAD Processor software which we had developed since 2016 with a great team of folks (now totally trashed by the company).
For me, XDE is a tool to read as much data as possible from a STEP file. Other than that, it does not bring much to the table and, what is worse, it's quite horrible at data manipulation scenarios.