Sehr interessante Disskusion!
Ich würde da gerne auch meine 2 cents dazugeben. 
Der Eingang eines Gebäudes kann ein Punkt des Gebäude-Ways sein, der entsprechend getaggt wird. Das ist eigentlich so üblich. Für POIs wäre das eher unpraktikabel ab einer bestimmten Menge an POIs, die sich alle neben dem Eingang reihen würden. Manchmal will man ja auch eine simple Art von Indoor-Mapping machen und die POIs entsprechend ihrer ungefähren Position im Gebäude setzen (z.B. in einem Einkaufszentrum).
Die Lösung per Relation finde ich persönlich sehr gut, schließlich besteht ja zwischen Gebäude und Geschäft eine “Beziehung” (Relation). Allerdings, soweit ich das bisher mitbekommen/gelesen habe, werden Relations versucht zu vermeiden, da man das ganze Datenmodell einfach halten möchte. Aber vom Prinzip wäre eine Relation wohl angemessen, um die Zuordnung für den User durch Vermeidung von Geocoding einfach zu halten.
Ich denke, da OSM ein Datenbank-Projekt ist, sollten auch die grundlegenden Datenbank-Regeln gelten, also Redundanz zu vermeiden. Redundanz bringt beim Bearbeiten (Edit) fast immer einen Aufwand mit sich, der höher ist als der Aufwand für’s Auslesen (Read). Für beides kann man Software nutzen, die den Aufwand verringert, aber Redundanz kann am Ende auch zu inhaltlichen Fehlern führen. Z.B. wenn ein POI mit Adresse verschoben wird, weil das Geschäft nach nebenan umgezogen ist und man vergisst die Adresse im POI zu ändern. Als einfaches Beispiel.
Redundanz hat imho nur selten eine Berechtigung in Datenbanken. Meistens geht es dann um Performance und führt zum Caching von Daten. Hier könnte man jetzt sagen, dass das Geocoding aufwändig ist. Nicht unbedingt für die Maschine, aber für den Menschen/User der nicht über die entsprechenden Kenntnisse oder Software verfügt. Da wäre die Lösung dann aber eine zweite Datenbank, wo ein Geocoding-Algorithmus die redundanten Daten erstellt und in die zweite Datenbank schreibt. Dann könnte man diese erweiterte Datenbank bequem nutzen und könnte sich sicher sein, dass z.B. bei der Adresszuteilung keine menschlichen Fehler im Spiel sind.
Eine andere Möglichkeit um eine einfache Zuordnung zu gewährleisten hat ja schon @NTGhost erwähnt, indem man Relations nutzt.
Ist ja das gleiche Redundanz-Thema nur eine Ebene höher. Allerdings sehe ich das hier ähnlich wie @R0bst3r, da Straßennamen, Postleitzzahlen oder Ortsnamen sich eher selten ändern im Gegensatz zu POIs, wo es im Grunde eine permanente Fluktuation gibt. Somit ist da auch die Gefahr von Fehlern sehr viel geringer.
Ich dachte, es soll nicht für den Renderer, das Navi oder ähnliches gemappt werden? Müsste das dann nicht auch für Unternehmen gelten?
Letztendlich geht es wohl nur um “Redundanzfrei + Geocoding” vs. “Redundant + Bequem”. Ich tendiere da auf jeden Fall zum ersteren, ist einfach sauberer und erheblich weniger fehleranfällig.
Hmm, ist jetzt doch mehr geworden, als beabsichtigt, aber egal. Ist ja schließlich ein echt interessantes Thema.
Sonniges Wochenende!
Offtopic:
Naja, ganz so einfach ist es nicht. Google crawlt die Seiten, bewertet sie mit einem Algorithmus und speichert lediglich die Meta-Daten. Außerdem ist die Datenbank von Google eine graphenbasierte Datenbank. Die funktioniert etwas anders. Google-Cache ist nochmal was anderes und hat mit der Suchdatenbank wenig zu tun.
Ja, deshalb muss ich regelmäßig bei Wikipedia zusätzlich oder gleich direkt die englische Version lesen, da dort meist mehr Informationen zu finden sind. 
Ich bin jetzt nicht so sehr mit Wikipedia vertraut, aber ich glaube den Ansatz gibt es bereits mit Wikidata als gemeinsame, sprachenübergreifende, maschinenlesbare Datenquelle. In den USA werden mittlerweile der Großteil der textlichen Sportnachrichten von Maschinen erstellt, da es oft nur um die Wiedergabe von statistischen Daten geht, die in nette Worte gehüllt werden. Wikipedia ist da in vielen Bereichen vergleichbar und ich sehe da auch die Richtung wo es hingeht. Eine Datenbasis und eine KI, die das in einen netten Text verpackt. Soll ja kein Bestseller-Roman werden. 
