Sry, didn't get your point ) Could you please give an example. I'm usually looking at this situation in the following perspective:

If you are speaking about POI's inside the building - OSM allows to create amenities as areas or points. 

1) So you can create one building and then inside create several POI's as areas (which are not rendered as buildings). This is somewhat beneficial, because then POI's by default inherit building address, so you don't need to fill it manually for each POI. You can also associate entrance to the area. You might say that such POI-area are not visualised in navigation apps - but this is not OSM fault, data was added, it's just not used.

2) Other option is to use point for POI. In this case you plot point near the entrance. And again POI inherits building address. This is how google and bing do on their maps. Basically they don't care about poi internal area.

Speak about navigators - they usually prioritise POI's visualization to building details, so most likely building name will be hidden, but you will see all POI's (at least as icons). Also in both cases when poi will stop existing in 3-4 years (avg restaurant life) you still will have a building mapped. 

But of course if any of this two approaches make data mess on the map, then smth must be simplified.

I personally prefer not to plot poi's as buildings at all when poi doesn't take over whole building. For example in a shed to the east of the Aquarium we have three restaurant. So someone splitted shed into three separate buildings. I would approach to the shed mapping differently: OSM have building layer and amenities layer, so you should try to split them when possible. 

However there is no strict guidelines. So open to discussion.

