Yeah, I'm glossing for simplicity -- the actual behavior is that the commits remain on disk until Git garbage collects them. With normal/default config, I think that's 14 days ("gc.pruneExpire"?) but it could be "never" or something like "instantly" depending on config, I think. I'm also not totally sure that any server-side stuff triggers GC behavior. We also don't currently ever GC explicitly, although this might change. My understanding of the Git GC is generally a bit fuzzy.

So the complete explanation is more like "... they will be unrecoverably destroyed [probably after a couple weeks unless you've changed Git settings]."

For mirror, I'm simplifying git push --mirror:

--mirror
    Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and
    refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force
    updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option
    remote.<remote>.mirror is set.

The remote there also needs to GC to really destroy stuff, and it's possible that someone might implement a git which does something magic here and doesn't actually delete anything when a client says "delete master", but I don't know of any Git which works like that today, at least. (Except maybe Phabricator, which says "no, I'm not going to do that" by default, but doesn't have any fancier sort of behaviors.)