@JanF - there are three problems solved by this approach.
The first issue is that IFC spatial elements (e.g. sites, buildings, elements) can store properties (attributes / psets / qtos / etc). In Blender, if you click on an object, you can see the object panel and manipulate it via the UI. However, in Blender if you click on a collection, there is no UI panel associated with the collection. So for convenience, an object is provided that people can click on. This is not the only solution - e.g. we can build our own UI panel elsewhere, but it is simply more convenient.
The second issue is that IFC spatial elements almost always have a placement. E.g. a building storey has an elevation value (e.g. a Z coordinate). Blender collections do not have physical locations. Therefore, at the very least, an empty is required, so you can set the placement. Technically, we can work around this and let users set the location via UI fields in a panel, but I reckon moving around an empty is easier.
The third issue is that IFC spatial elements may have representations. E.g. a building or site can actually have geometry associated with it. Therefore, we need an object. In this case, we need more than an empty - we need an actual mesh object.
Making the empty name match the name of the collection is just my way of forcing users to be clean :) Theoretically we could choose one name to be the source of truth and ignore the other, but ... Also, it can get a little confusing especially when some software (I'm looking at you, Revit!) decides to export a ton of objects which aren't IfcSite as an IfcSite.