Yes, always anticipate coordinates to fluctuate.
Though the building is not likely to shift on the earth's surface, using coordinates as identifiers/keys for addresses is a bad idea because the data set is going to move from underneath you:
Accuracy a matter of definition. Is an address most accurately pinned at its mailbox, or its largest structure, or the front door? Which front door? Maybe the driveway?
Decimal precision is another concern. Is
33.754208 the same as
33.754209? This can be fixed by rounding, but then you lose precision. Adding decimal precision is a luxury you may not have. No matter how precise your decimal is, they're likely to be different (especially considering how computers compare float types) even if they're "the same". You're wholly dependent on low-level implementation details at this point.
When you don't control the data set and you're using a physical attribute to key something, you can't guarantee that the key won't change. But that's a problem because your database expects the identifier to be unique and constant. Even if you update it, what about collisions with another data point?
Even if you do own the data set, you're subject to the first two problems. Definitions and implementations change. You could just never update your coordinate data, even for better "accuracy," but addresses still change whether you like it or not, invalidating your cache.
What you can do, though, is own the key. Don't use coordinates as identifiers; rather, assign a key that is guaranteed to be unique across your application (or possibly the world) and don't ever let it change.
At SmartyStreets, I deal a lot with geocoding addresses. For instance, that address is a building default. It's missing a secondary (apartment/suite) number. Though our data is block-level (near-rooftop), if we could get as precise as possible, what would its coordinate be? Right now, we assign it
33.75425, -84.38721 which is only a few feet away from where Google Maps puts it. Should it be a different coordinate if it's the lobby vs. a unit in that building? The answer to that question can change, thus changing the underlying data set. And what about units that are right above each other (you can pin a point in a building, but which floor did you mean)? Google obviously goes through the exact same questions, and if the answers change, so do the coordinates.
As such, we always recommend that people give the address a key that they control to uniquely identify it, and never change it.
Addresses are a mess. They can change too, especially if you start asking the philosophical questions about "What does an address really mean? Does it represent a building or resident? Or a mailbox?" and when you start considering that addresses are temporal, meaning that they change with time, it gets even uglier.
We also hear of people that try hashing the addresses or using the delivery point barcode as an identifier. Don't do that, because even in a standardized format, addresses can change and yet still be the "same" address. And the delivery point barcode, erroneously thought to be unique for an address, is doubly guilty: it changes and is not necessarily unique. Cool, huh?
tl;dr Make your database rely as little as possible on the actual address and coordinates.