You can certainly use an aggregate. I notice, however, that your aggregate class is called
IfcBuildingElementProxy. You may consider
IfcElementAssembly. I find the IFC documentation vague on exactly when an
IfcElementAssembly should be used compared to any other IFC class aggregate, so hopefully someone here can clarify that.
For your general questions:
It is not better to use ElementType or Element. Both serve different purposes and so it cannot be said that one is better than the other. An element represents a single element instance - e.g. the physical HVAC assemble at a specific location in your building. An ElementType represents a typical construction typology. E.g. you have 5 fire sprinkle elements, all of the same fire sprinkler element type (i.e. the same model purchased from the same manufacturer)
The complete hierarchy is not required. Only the “IfcProject” itself is required. From there, the hierarchy can be as you desire. What you’ve shown there is simply a preset default as an example. You are free to customise it. Note that despite this, some vendors do not support more complex spatial hierarchies. For example: https://wiki.osarch.org/index.php?title=Revit_import_pitfalls - where an OSArch user has reported that if a building storey is missing, Revit will fail to import the IFC. If you come across issues such as these, please help report them to the OSArch wiki so we can document the various quirks that users have to face.
It is theoretically feasible to dump the data you’ve shown into a custom pset. However, I would highly recommend looking to see if there is a more ISO standard location to store the data instead. Otherwise, this defeats the purpose of IFC. The point of IFC is standardisation, not just data transfer, of which there are plenty of alternatives. For example L25-26 shows a classification. This should be stored in a classification relationship. L37-39 shows an operating voltage, which I suspect already exists somewhere in an ISO PSet.
Hope it helps!