snap does not cryptographically verify all packages, unlike apt

This isn’t correct. Run snap download htop from your terminal and you’ll receive two files: The actual squashfs image that gets mounted in /snap/htop/<revision number> and a .assert file that cryptographic signature data about this snap file. Modify the squashfs image and snap won’t let you install it without passing --dangerous to bypass that check, just like apt-get’s --allow-unauthenticated.

The problem here exists at a different level: the level of what’s getting signed. Conceptually speaking, running sudo snap install htop is a bit like running sudo add-apt-repository ppa:maxiberta/htop && sudo apt install htop. The package is built by the owner of the snap/ppa, and what Canonical is cryptographically verifying to you is that they got this from the owner of the (snap|ppa). This is roughly equivalent to domain verification for HTTPS (the type of HTTPS certificates Let’s Encrypt uses).

There are some different security considerations. For a snap, you need to be aware of the publisher each time you install something new. For PPAs, on the other hand, you only have to worry about this when you add a new PPA. However, the trade-off also works in the other direction. One snap can’t just replace another snap on your system, whereas a malicious PPA could provide, for example, a malicious libc6 update.

These are both different (and lesser) assertions than what Ubuntu makes with its standard apt repositories. But they are still cryptographically backed.