I would never use building and building:part for the same closed way of a building. There is no necessity although it is possible. Only for multiple building:part within a building it sounds reasonable. Only building:part on a closed way is definitively wrong usage cause it will be ignored by most osm users.
I also prefer to add the address to the outline, even if there is a building relation. Why? Because addresses are most of the time at the outline … But both is correct.
I also divide strictly by building:* and roof:*. Both of them are independent of each other and don’t change if another mapper changes only the height on the outline. But that is just my approach.
2D renderers aren’t aware of the building relation, since building relation is a 3D feature. So 2D renderers won’t know about building address if it’s placed on the bulding relation. Therefore placing building attributes on the building relation is wrong.
Building attributes must be placed on the building outline.
Does that mean that when a closed way representing a building outline, completely matches up (coincides) with one of its building parts, then we need to have two different closed ways: one representing the building outline, and another one representing its building part?
I see type=building relations primarily as a means to “group” all building:part and the outline together. If you don’t use a type=building relation, there is essentially nothing that tells you that all these parts belong together, they might as well be different buildings. It also helps in navigating the different parts in the OSM editors like JOSM and iD, as you can go “up” to the building relation to see which parts belong to it, and then drill “down” to a specific part if you want to modify something.
Of course you could use just a generic relation, but type=building is already documented, and I think makes sense using in this context and to distinguish it from other types of relations.
I don’t see any conclusion at all: 2 people want to keep the relation, one wants to keep it for complicated situations, one want to get rid of it. Typical situation for OSM
Since 3D is not that widespread yet, people will keep on choosing one of the methods until one wins (i.e. gets used a lot more), or all data consumers support both models, in which case the ones that do not want the relation “wins”.
It’s usually bad practice to map a building with both building and building:part since the part is usually smaller that the building, and the building tag should also have tags that depict the whole building (full height for example).
So if your building only have ONE part, simply tag using building. if it has MORE THAN ONE part, map the outline with building, and all the parts with part. 2D wise, the sum of all parts should cover the outline.
Relations are useful when it’s not easy to associate a building:part to a building outline, for example when the part overlaps 2 outlines (2D wise). Otherwise it can be convenient to use a relation to sort through the differents parts, but it’s not required.