Traditional package management on Linux has a lot of strengths. Dependencies can be shared, which keeps things small and efficient. They generally go through a committee of some kind, and thus several eyes (this varies between Linux distributions, some have less of a process than others). There's usually a central place to log bugs, too.
Traditional package management has some downsides, however.
For example, when you release the new version of libfoo, literally everyone using the distro gets that new version. This means that distribution maintainers must be incredibly conservative when shipping updates. They can't regress.
Also, it's pretty rare to see the upstream developer of an application go through the work of packaging their application for the various Linux distributions out there. Especially once they realize that they won't be able to ship their updates as easily as they expected. For example, on Ubuntu, once a stable release is cut, new features are generally not allowed to be added to software in the distro. Only security fixes and bug fixes. And even that process is heavy. This is how Ubuntu stays stable, but it's also how the Ubuntu archive gets stale through the lifetime of the release.
Another issue (this is a downside or an upside depending on how you look at it): generally in order to get software into a Linux distribution, it has to be open source. Not everything is.
Snaps are different in a few ways. First of all, their dependencies are bundled into the same package. This means they can't be shared, so they aren't as efficient as traditional packages, but the reason this is done is to work around the libfoo example I just provided: it gives snap developers the freedom to change things as they see fit without potentially breaking unrelated software. As a result, they can be distributed out of the Linux distribution entirely, with no committee involved. In fact, it's very common to see the upstream developer of an application creating and maintaining the snap for their application, because they know they can ship an update to their users whenever they want, and if they break something, they only broke their users, not half the distribution with their libfoo breakage.
Snaps are also just squashfs images that contain... stuff. There are no licensing restrictions. This makes it possible for Microsoft to release Skype as a snap, or Spotify to release their player.
As a result of the fact that they bundle the dependencies and are just a squashfs image, it makes it pretty easy to install and run them on any Linux distribution, regardless of that distribution's built-in package management system.
Will new applications eventually migrate to Apt (or other Linux package management systems), or will Linux users have to run two different package managers to get all the applications they want?
Yes, traditional dependency management systems aren't going away. New software will over time be available via apt. But that will continue to be done by community members who just want the software in apt, not by the upstream developers themselves. And depending on how your Linux distribution works, that software can get stale over time until you upgrade to the next. Generally speaking, if you want the newest stuff, you need to get it from the upstream developers. They seem to be choosing snaps to do that more and more, as you've noticed. PPAs (or similar) are another option.
Anyway, this isn't meant to be a complete pros/cons list, there's a lot more we could talk about here. I'm just trying to point out that each way to consume software has a purpose, and neither is going away.
