I think the existing text is clear enough, and mentioning examples of application-dependent behaviour would not improve it.
In fact, I believe that applications should not rely on the existence on the relation, given how a large number of 3D buildings already do not use a building relation. It’s not really a problem to algorithmically determine which building parts belong to a building. At this point, encouraging the use of the relations (except in the very few cases where they are actually necessary, e.g. overlapping buildings) only makes 3D mapping look more complicated than it actually is.
Agree, that application should not rely on existing relation. But I would consider not to have relation for multiple building parts as bad practice from two reasons:
Relation provides the easy way to find all building parts and interact with them as single object (btw, what else can be used to find all parts for specific buildings?). This is useful for exporting building to some 3D modeling tool (e.g. blender) to perform further processing. Another example is from games: assigning specific action when collision with building is detected (for example, “you’ve just found Bundestag, destroyed White House” etc…).
As I mentioned, performance. One example from my project which tries to generate city environment dynamically in Unity3D targeting mobile/VR devices. If there is no relation, then I have to render each part as separate object (GameObject in terms of Unity3D). However, it is costly: a lot of additional things are associated with each object. For example, physics specific (e.g. mesh collider) and app specific (e.g. scripts/behaviors).
All building parts must be geometrically inside the outline polygon (tagged building=*). This can be used to find out which parts belong to which building using a basic “is this geometry inside that polygon” test. The building outline then becomes the single “parent” object, with the name and other relevant information.
I believe this is only a problem if you don’t combine the building parts inside the outline to a single object. Of course, there is a one-time performance impact from the polygon tests, but the effect on physics calculations, scripts etc. you mention could be avoided just as they are with relations. It really makes no difference in that regard.
This sounds like “many to many relation” in terms of relative databases which is quite expensive to process and makes osm data parser more complex than it can/should be.