Snap is the wrong solution to the problem, and every time some big project switches to it (or any of the other awful systems like Flatpak and AppImage), I shake my head.
The problem of the balkanization of Linux distributions isn't solved by an app system that takes away all the best parts of Linux. The great thing about Linux is that you didn't need fifty copies of every DLL, that you could fit an entire working system with complete office software, in a tenth the space of a similarly "capable" Windows system. Making a system that essentially wraps everything an app needs in its own little mini-distro is awful. It costs storage space. And it costs RAM. Each application needs to instantiate its own set of every shared library it uses, so you can end up with ten instances of the same shared object in ram. Even to multiple libc's.
The FHS then LSB were the correct answers. The answer was and still is standardization on the back end. Standardize the basic system and libraries, standardize where packages are installed to, then keep going and standardize the way packages are installed. The distros can keep their rpm and apt/dpkg, I don't care about the command name or its command line switches. But each of them can and should call a more basic level library whose API is the same for every distributions to do the final work.
The problem is there is too much money on the Red-Hat esque side of the fence interested in making it NON-compliant with any standard. And, in fact, in pulling it back from even being open source as much as possible. The rest of the Linux ecosystem, though, needs to hang its head in shame for allowing distro balkanization to happen to this extent.
Any big-name software projects needs to just say no to the bandaid "solutions" like snap flatpak, and appimage that apply just enough bandage to the situation to keep the incentive away from fixing the problem properly.