With the requirement to compress many geometric network many feature classes into a few fixed feature classes for the new Utility Network, many additional sparsely populated attributes from disparate data sources must be merged into these asset feature classes. Sparse matrices always feel "wrong" to me.
The AssetGroup and AssetType is a fine way to apply distinct rules and rendering. However, over many business domains, say, Asset Life Cycle, Construction and Supply Chain, Engineering Design and Analysis, CRM, and Public Safety, it seems that one would need to create a lot of different domain networks, so similar, but with potentially vastly different attribution.
With the advent of automated data collection and classification provided by self-driving vehicles, drones, and Machine Learning, it would seem that the so-called "document" database (e.g. Mongodb) or other NoSQL databases at large scale may be useful to provide input into the ArcGIS Enterprise world of the Utility Network.
I don't have a good way to explain this other than to analogize it with inversion of control, where the GIS contains enough attributes to render and apply connectivity and association rules, but the true data-store is a behemoth cloud-based Storage or document database type of service.
So an asset feature class could, say have an AssetGroup and AssetType and a AssetBackendVectorPointer to this large data-store being continually refined and updated. Then a well-refined API or perhaps even a best-practice design pattern could develop to really address the asset as a real world first class extant object.