kernel volume: Qubes OS exposes a kernel volume for the qubes to boot a kernel made available through dom0 updates. This kernel is used by qubes by default and eases maintainership of Qubes to have a same kernel+initrd used for all appvms, properly tested, instead of having the OS deploy and use a linux distro specific Xen compatible kernel. One can switch the behavior, but this is not subject of your question here.
For the 3 other volumes, the notion of persistence and inheritance from Qubes documentation is needed as a background: Templates | Qubes OS
volatile volume: The volatile volume is another exception not taken into consideration in snapshots. The volatile volume is a read/write root overlay, aimed at giving the qube the illusion that / is read/write. As the name gives insights about, this volatile volume is discarded by that qube at shutdown. This volatile volume overlay is the reason why yo ucan install applications under a qube that will not be available on next reboot, unless that application is installed in the Template.
private volume: relative mainly to /home. This is basically what a “qube” is. It contains qubes related data, outside of the template. This one is “mounted” under /home under a qube. So snapshots of a private volume will give different point in time versions of user’s related content.
root volume: relative to / (also called “root”). This is for templates, and contains all the filesystem. This is basically the operating system. Snapshots of root volumes will give different point in time versions of OS related content.
There would be no reason to keep snapshots of neither kernel nor volatile volumes.
Having revertible snapshots of root and private volumes makes sense, because those would be desirable to be revertible.
Qubes keeps 2 revisions by default of any root and private volumes it created, outside of dom0’s root volumes.
Let’s picture that quickly:
[user@dom0 ~]$ ls /dev/qubes_dom0/vm-personal-private*
So one could, cautiously do two qvm-volume revert personal:private here, where doing so would revert first to epoch timestamps 1668974971, second would revert to earliest snapshot with epoch timestamp 1668544875.
The same applies to template’s root volumes and private volumes, or standalones private and root volumes.
That thread is relative to creating dom0’s root snapshot which are currently not created by default.