snapd developer here.
The word protections seems to imply that snapd contains some sort of DRM system to protect binaries. There's no such thing. Snapd protects your system from possibly untrusted software and various software packages from affecting each other.
Differences from Virtual Machines are simple, there are no virtual machines involved. Running a program in a virtual machine really runs a program, operating system and a hardware emulator as one big process on your system. Snaps don't use anything like that, they instead executed directly on top of the hardware and the kernel provided by the host system.
Differences from ordinary processes are just a few but they make all the difference and magic possible. Snapd uses multiple features of the Linux kernel to give snap processes (processes of started snap applications) different view of the file-system, so that they can run on top of virtually any modern distribution. In addition the interaction of such processes with the kernel and other userspace programs is controlled by a sandbox managed by snapd. The exact behaviour of the sandbox depends on the system used and the set of snap interface connections made between the snaps in the system.
The term container means pretty much nothing today, it is just a marketing buzzword. The linux kernel offers a wide range of tools that allows to segregate various parts of the system and make some of them appear unaffected by changes made by other processes elsewhere. This may range from "it looks like another machine" to "it looks like this machine" and is constantly evolving and expanding in scope of what can be done.
Differences from other "containers" like docker is the set of those primitives used. Specifically snapd uses the device cgroup, the freezer cgroup, the seccomp BPF filter to constrain system calls and a large set of apparmor profiles to constrain access to IPC mechanisms, networking mechanisms, signals, capabilities, read, write and other access to files on the system. Docker or other "containers" typically use different set of such kernel features and configure them differently.
From a purely perception difference snapd is designed to integrate with the host. If you snap install a service it will be directly visible to your machine's service manager (systemd). If you snap install a CLI application you will be able to run it mostly like any other application on your host. If you snap install a graphical application it will integrate with you launcher, panels and other typical controls. This is not the case for docker which is designed to allow you to run, typically, headless network payloads and leave the integration to the user.
As for data protection snapd manages and retains application data between revisions to allow users to revert to a prior working revision as well as contains default permissions that limit access to potentially sensitive access to certain files in the home directory. Still most of the home directory is currently allowed as the mechanisms to mediate access are incomplete or immature. Over time that access will be restricted and only granted through fine-grained mediation.
There's a sophisticated white paper about snapd security model that I could recommend for far more details than those that I presented here: https://developer.ubuntu.com/static/resources/ubuntu-core-16-security-whitepaper.pdf
