Debs work really well when they are shipped as part of the distribution deb archive itself. They work really badly when third parties try to use them to provide add-on software to an existing distribution release.
The main problem that Snaps solve is this latter case: when third parties are trying to ship directly into someone's distribution installation[1].
Often third party debs appear to work OK, but then break future distribution upgrades. By then users have forgotten about the third party software that has hacked itself into their system, and blame the distribution for their upgrade failure. The problem is that distribution debs are designed to provide metadata about what has changed so that the package manager can accommodate. But it's not possible for distribution debs to be aware of the third party debs to handle those changes. So things break.
The breakages caused by debs aren't just limited to future distribution upgrades. A bad third party deb package can break your entire system. We routinely get reports where it turns out that this is what happened to our users!
There's also the problem of dependencies. If a third party app needs a bunch of dependencies, then they can't realistically bump those dependencies on the system as a whole without regressing all the other apps that need older versions of that dependency. So they have to bundle their dependencies, and this is something else that regular deb tooling doesn't handle well. You can theoretically construct a deb that bundles all its dependencies, but then that's exactly what snaps and snap tooling handles better - that's half the point. Nix only partially solves the problem by better supporting concurrent installation of multiple versions of those dependencies. But those concurrent versions would still each have to be maintained; that's something that distributions try to avoid by picking one version of each dependency and making the entire distribution release work with just that one. Moving that maintenance responsibility to each third party app developer, and having the packages bundle their dependencies, is the other solution. This was already happening with deb packages like for Firefox. Firefox upstream bundles nearly everything, and the debs (eg. in Debian) do the same for most of their dependencies. Snaps just call a spade a spade and are designed around it.
You also wouldn't really expect a third party app to have access to everything on your system. Say for example you download and install some game app to try out. Do you really want it to have access to your online banking browser session? The game developer might not secure their development infrastructure as if someone's trying to steal their users' money, because that's expensive and they're only shipping a game. But if you install their game, then that's what you risk. That game developer's infrastructure is suddenly an attack vector for an adversary that wants to get to your online banking session. On iOS and Android, each app only has system-mediated access to everything outside its sandbox. Debs fundamentally cannot provide this separation, so if you install third party debs then you're giving all those third parties access to everything, which really is unacceptable in modern security practice. Snaps give you that sandboxing.
So that's what snaps are for: 1) bundling dependencies, because that's necessary in world of third party software that ships independently of the distribution; and 2) sandboxing, because that's necessary in a world of third party software if you don't want to give all those third parties and their adversaries root on your system.
If you don't want third party apps, and only want what your distribution ships in a curated manner, then you don't really need snaps. But consider that Firefox is essentially a third party, non-curated app, regardless of your distribution or how it was packaged! See [1] below.
Snaps are also immutable, which really helps with stability and upgrade and revert cases. This is more relevant for snap-only systems like in IoT, not the Ubuntu desktop. In an IoT deployment you can't tell the user to run "apt-get -f install" to fix up the system because power got interrupted during an upgrade - because that's how debs work.
In years gone by, Ubuntu tried really hard to make third party debs work. But it didn't work for various reasons. In the meantime, it became the norm for third parties to ship debs together with all of their problems, since there was nothing better possible at the time. This is what snaps solve.
Disclosure: I work for Canonical. But here I am speaking for myself, not my employer. I'm not involved in the design of snaps, but as a distribution developer, it's clear to me what problems they solve.
[1] Packages like Firefox also use snaps because even as a deb it's really not the case that Firefox is curated by the distribution and mostly unchanged after release any more. So it suffers from mostly all the same problems that third party debs do.