Two routes lead back out of a snapshot, and they differ in thoroughness.
Single files
In the comparison, files can be selected and only those reset. The usual case: a stylesheet broke yesterday, everything else should stay.
The whole project
Restore everything resets the project to the snapshot’s state. The sentence in the question is the important one:
Files that did not exist back then will be deleted.
So a restore is not an addition but a return. Whatever came about since is gone afterwards — unless it is in a later snapshot.
There is always a way back from going back
A snapshot of the current state is taken automatically first. That is in both questions, and it means: even an accidental restore can be undone. The new snapshot carries the label Before restore.
The special case: undoing a core update
Restoring offers an extra switch: Also reset the project commit.
It is needed in exactly one case — when a core update is to be undone. Without it the files would come back, but the project’s git history would stay at the new state, and the updates page would keep reporting everything as current.
One note on it is meant seriously: if that commit has already been pushed, the local state then diverges from the server. That is to be sorted out before the next sync.
What a restore does not bring back
The vault, when the content folder is linked. It was never in the snapshot; QuartzControl says afterwards explicitly that its files were left untouched and that everything outside the content folder has been restored.