Many Wikidata items suffer from dual-tagging just as many OSM features do, though I think there’s a general awareness that dual-tagging should be reduced over time. Wikidata’s built-in validator encourages contributors to clean up constraint violations often caused by dual-tagging.
Splits, merges, and other geometry changes do complicate any kind of persistent referencing, and that’s before getting into the linear referencing required for routing. I’m reminded of how, years ago, my edits to smooth out curved roads by adding new nodes would cause Mapbox’s traffic maps to show a banded effect along the road because the traffic data had been associated with segments between nodes that were no longer adjacent.
I guess you weren’t thinking of OpenHistoricalMap when you called for a separate database. 
But you can perform these exact queries using OHM’s Overpass API endpoint, provided that the restaurants have been mapped and tagged with start_date and end_date. For example, this query shows the bank branches that closed in my hometown since 2000:
[out:json][timeout:25];
nwr["amenity"="bank"]["end_date"~"^20"]({{bbox}});
out geom;
Even so, a given OHM way ID isn’t strictly guaranteed to be permanent. The way might get revised or deleted as mappers learn more about the local history. This is not uncommon among datasets. For example, U.S. mappers like to think of a GNIS Feature ID as a permanent, unique ID, but these IDs can be fungible too under certain circumstances.
(Most of the data in OHM is CC0-licensed, by the way.)
A similar problem even arises when mapping things that aren’t changing. So far, just about every proposed solution for relating the elements of a street together has run up against the challenge of delimiting a street: Is “West Market Street” the same street as “East Market Street”? What if a street briefly becomes a pedestrian mall? What if the physical roadway curves to the left but the name continues onto a side street to the right?
I think this uncertainty is partly what has motivated a non-relation-based approach to relating sidewalks to streets, but at the cost of some indirection, duplicating information about the intended target on the related ways:
By analogy, in the absence of robust linking between OSM and other datasets such as Wikidata, there’s bound to be some less formal duplication. Population figures, translated names, etymologies, and owners can end up in both the OSM silo and the Wikidata silo.
Apart from losing a Michelin star because of the new chef, these are the cases where OpenHistoricalMap would duplicate the feature. When in doubt, it’s a distinct feature. However, this adds another headache on top of OSM’s version of the stable identifier problem. A chronology relation can tie together the time-separated copies of the feature, and this relation can serve as a relatively stable entity for external linking. If someone wants to map the ship of Theseus, well, that’s fine: there can be multiple chronology relations for different viewpoints about when it became a new ship.