Hi,
I don't have answers to all of your questions - but I'll do my best to give you some insights in where/how to dig.
1. When we established our UN those nonspatial tables were related to their corresponding feature classes. However, I've never tested what happens during an export subnetwork call with related features. I would try creating the relationship class/relates and then testing to see if the information you are looking for appears in the JSON.
2. When you are staging your UN, you should take time to determine if all of those fields are necessary. (Recognizing that some network attribute fields and system fields are required - like association status.) The UN is additive - once the field exists you can't delete it. We are not currently exporting related data with our export subnetwork. We do however use a different product to build subnetworks as JSON and use our Azure Integration Platform to create some custom files for our OMS system. There are lots of possibilities as to how to automate and make the data work for you.
3. Our OMS connects to the UN feature service through the REST API call (calling export subnetwork). Those subnetwork JSONs then go through a complex configuration / data mapping process. How your ADMS will import the data is 100% dependent on the specific system. Some of our other applications (CYME, ODMS) ingest/parse through the AIP platform the export JSONs that we manage through a third party application. I would reach out to your ADMS group and identify the best method for you - there are pros and cons no matter how you do it.
5 - Our biggest performance gains have occurred through ESRI patching and staying current on the enterprise server side. Other tips include: making sure your have enough cores and CPU on your database servers, being meticulous with your scale settings, ie: nothing draws above 1:5000 (an example), publishing feature services without subtype group layers enabled, workload separation at both the database and enterprise level, feature service settings such as refresh time and the length of time a user is able to hold onto an instance, monitoring/analyzing query stores to see where you are losing performance. For example, there are major performance gains in (Enterprise 10.9.1) patch 6 (I think) around drawing the subnetwork line feature class. Prior to patch 6, this was consuming about 40-60% of my database CPU. There are database reports you can run to check for errors from the DB (oracle, sql, etc.) side to find inconsistencies that maybe slowing down your system - especially around topology.
The utility network is the foundation of a true "system" - you need to examine all parts of the ArcGIS system to understand where you may be losing functionality. Start examining the parts of the system to see where efficiencies can be gained.
