That may be a typical workflow for your team, but I'd say that it's not a typical workflow in general.
Shelvesets are intended for short-term suspension of work in progress that's not quite ready to be committed to a dev branch, generally in the case of something exceptional occurring that requires immediately switching contexts (e.g. troubleshooting or fixing a bug).
Internally, TFS actually stores most files as reverse deltas. Why? Probably because the most frequently accessed state of a file is the current version, and having to "build" the current version by playing forward a series of changes to the originally file is going to be a lot more expensive. Basically, when you go to look at an old version of a file, it takes the current version of the file and "peels off" the intervening changes until it's back at the old version.
Your specific question is actually directly addressed:
Shelvesets also use the same mechanism for storing their content. However, with shelvesets, no deltafication happens. Each shelveset gets a new copy of its file(s). (except in the case of a merge). When a shelveset is checked-in, a shallow copy occurs and the committed version of a file uses the same content as the shelveset copy of the file referenced. Deltafication will be started on the previous version of the file(s).
So, long story short, shelvesets are not based on changesets.