…at the wrong ones though 
/snap/chromium/958 is a mountpoint, you are looking at the content of a compressed readonly filesystem file that happens to be loop mounted there … the actual size it occupies on disk can be found via:
$ mount | grep chromium\/958
/var/lib/snapd/snaps/chromium_958.snap on /snap/chromium/958 type squashfs (ro,nodev,relatime)
$ ls -lh /var/lib/snapd/snaps/chromium_958.snap
-rw------- 1 root root 154M Nov 26 09:28 /var/lib/snapd/snaps/chromium_958.snap
… indeed, that you have multiple revisions on disk makes it occupy more space in the end but not as significant as it looks like from looking at the mountpoint content 
Also note that desktop snaps are only a fraction of what is in the snap store, on the “snapped-server/cloud-software” or “snapped-iot-software” side many snaps make actual use of the builtin auto-rollback features and self-testing that come for free with the snap package format … sadly you cant have (auto)roll-back features without having the former data and binaries around, so the above is a design requirement.
…and the same goes for home dirs … which is why snaps execute with a versioned home dir pointing to ~/snap/<packagename>/<version>. We allow you to disconnect the home interface at any point in time for any snap (and on some systems it does not get auto-connected at all). To still give an application a proper $HOME to work in even when there is no way to access the real users home they default to this setup. So the difference you see between deb and snap regarding home dirs is also by design…
