Object labels are only a thing in the diagrams in that chapter, not in R. R objects have names, which are bindings to locations in memory (the physical stuff, though still slightly indirectly) identified by addresses, which is what lobstr::obj_addr and tracemem are showing.
Thus, @jcblum is correct: the addresses are changing even though the name is not:
x <- Sys.Date()
tracemem(x)
#> [1] "<0x7fd63243fc98>"
x <- as.double(x)
#> tracemem[0x7fd63243fc98 -> 0x7fd6362378d8]
untracemem(x)
That does not mean it's necessarily a new object, just that R had to rearrange underneath to fit its new structure. From an R perspective, whether x gets overwritten or changed above is a bit unclear (and doesn't really matter). From a hardware perspective, it is a new object, presumably because your computer needs to reallocate the memory previously claimed by the class attribute.
Even when we would talk about an object in R definitely being changed, not overwritten, the R story may still not correspond to the memory story, e.g.
y <- 1:3
tracemem(y)
#> [1] "<0x7fd632e33d88>"
names(y) <- letters[1:3]
#> tracemem[0x7fd632e33d88 -> 0x7fd633507d48]
untracemem(y)
In this case, your computer needs to allocate new space for the names attribute—the previous space in memory was too small! Even though the R object is still the same, in your computer's memory, it is now in a new location.
Ultimately, the awesome part about R is that we don't have to care about memory and pointers and such most of the time. There's a reason that coding moved to higher-level languages: Managing memory yourself is a pain and error-prone. You can still do it in C if you need the control, but it is in no way necessary to become an awesome programmer/data scientist.