Slightly more technical answer but…

*Nix systems (GNU/Linux, GNU/Hurd, BSD, Solaris, etc) tend to use a common set of system libraries. If you ever watch an upgrade, these are all those packages that look like lib that seem to take forever Windows systems have something similar, except they’re called DLL files. Same idea, really. The libraries are basically sets of pre-canned calls other software uses to do things on the system. Different libraries do different things fron handling low-level stuff like menory and disk access and standard system calls, to calls to specialized hardware, video acceleration, audio-- whatever There’s a parallel system on Windows that does similarly. Theres a system under the shells and launchers called a Dynamic Linker that invokes the libraries when the application launches that “links” the binary application to the required libraries. It scans the symbol tables in the bunary and caches right libraries for the app in memory. It’s the stuff of 300-level Comp Sci courses, so I’m doing it a really rough explanation here.

*Nix system distributions ship with LOTS of little executable programs. Many of them are support apps that do things behind the scenes like run the logging system, execute background updates, execute the widgets in your graphical desktop. All of those programs generally to rely on the library files that are installed on the system. It economizes on storage which used to be expensive. It also benefits most apps because when the library gets updated for security or efficiency reasons, all the programs using that library also get the update. You don’t have to update all of the executable apps, just the core libraries.

Unfortunately, this introduced some inherent conflicts. Many times library updates would introduce new feature or usage that wasn’t always backwards-compatible with older code. Major library updates often required all the apps that rely on them to update or you could break your system. Package managers introduced the dependency trees to account for this, but it was often the case that major updates broke stuff, and sysadmins could spend days sorting it all out. In Enterprises where time is money, that got expensive. Add to this that dome distros update software versions infrequently, so the whole ecosystem needs to be maintained holistically because newer apps might require newer libraries that break other, older packages.

Snap, Flatpack and other “atomic” distribution formats get around this by leveraging a feature of the Linux ecosystem called Linux Executable Containers (LXC) (windows has this too). You might have heard of Docker or Vagrant. These are two LXC(-like) implementations that basically create what’s called a Kernel Namespace that acts like a sandbox or a container for the active app and its libraries. The application ships as a single image that contains a filesystem with the executable binaries, the required libraries, and the linker to make it go. The host system mounts the image as an overlay filesystem on the root filesystem and then runs the application in that filesystem within a private name space with its own RAM and system calls. Their are pros and cons here, but overall this is a popular way to maintain and distribute applications.

The cons that folks largely object to with containerized apps is loading time. LXC co trainers are meant to be immutable, meaning they don’t store data persistently within the image. When the app loads, and this is generally whenever the app loads, the linker has to scan then cache all the libraries within the namespace because it can’t take advantage of the caches on the host system. Likewise, because the container is a private name space, user and desktop access needs to be ported through some middleware because Tue container doesn’t necessarily have direct access to the system hardware or environment. It can make loading tines linger, and introduce timeouts or delays interacting with the app. Plus, since every app ships with its own libraries there is a lot of extra storage needed. Its duplication of effort, but that’s okay because now disk is cheap, and CPUs are fast.

So at the expense of storage and maybe a longer loading time, we can distribute images for Linux systems similar to how Windows ships their apps: a big, self-contained binary image that can run relatively independently of the core system. This means as long as your hardware can support the app and the kernel understands how to run the code in the container, you can decouple the user applications on a system from the core system that runs them. It’s a great proposition for code repeatability and cross-platform support You can run RedHat optomized apps on Debian systems, and vice-versa without worrying about library compatibility or base image versions. Developers like it because it avoids dependency conflicts, old repos, 3rd party repos, and makes the install repeatable across different distros. System maintainers like it for the same reasons. It make support much easier for everyone.

In less clesr on the nuances between Snap and Flatpack, other than Redhat and Canonical seem to like Snap, and everyone else seems to use Flatpack Canonical is leaning hard into Snaps for user software distribution. Not everyone likes that. OP went with a more vanilla distro, but can turn on Flatpack with a button in his software store.

So this was a wall of text, but I hope someone finds it helpful. Apologies for typos, editing is hard in mobile.

(Edits; clarity, typos)