Unfortunately, Flatpaks are the new SystemD. As in, a solid technology which solves real world problems but will face immense resistance from a community filled with splinter groups that have their own pet technology on the same niche, and will accept absolutely nothing else as an alternative. There is simply no path to standardization in this community other than big players like Red Hat and Canonical strong arming their pet technologies in, much to the disdain of everybody else.
As for me I'll keep using Flatpaks as they work great and have wide support. Alternatives are either obnoxious to use (Nix and Guix) or lacking in basic functionality (Appimages).
Flatpaks are not meant to replace established package managers, but to act as a supplement to them. Flatapak's design decisions go to huge lengths to ensure they are a side-by-side system with default package managers e.g. the notion that Flatpak packages have a different XDG_CONFIG directory so as not to conflict with applications installed via the main package manager. Therefore the argument that they are harmful to distributions is absurd, as there is no aim to replace your precious "properly" managed dependencies and the option to never opt-in will be always available.
If flatpaks weren't in competition with packages repos they would serve no purpose. They are explicitly in competition with package repos. They exist so that app developers can get their work out to users without cooperating with downstream packagers.
Overlap in functionality does not equal competition. They exist so that app developers can get their work out to users without cooperating with downstream packagers yes, but that does not keep anyone from packaging applications using the traditional methods.
Exactly, app developers who opt for flatpaks no longer have to give a damn about downstream. App uses an ancient version of OpenSSL that downstream won't package? No problem, use a flatpak. App needs symbols from a dropped API in ImageMagick and downstream won't package the out-of-date library? No problem, use a flatpak.
When app developers needed to work with downstream, end users won because it forced app developers to keep up with the environment to meet the requirements of repo packagers. Flatpak is directly in contest with this, trading packaging efficiency and keeping apps up-to-date for app ossification and upstream convenience.
People can correct me if I'm wrong, but I think Ubuntu even allows double-click installs of downloaded Debian packages. Is there a complexity here that I'm missing?
----
As far as I can tell, the parts of distribution that Flatpak makes easier aren't the literal distribution parts. Yes, they make it so you need to create fewer bundles (just Flatpak instead of deb, rpm, etc...). But they're more about the containerization than the distribution, if all you care about is distributing Debian packages outside of the official repos, that isn't necessarily that hard of a problem. I think you can even host a custom package source on a static site through Github pages, you don't even have to pay for the server.
The big change here is that you don't need to share dependencies, but importantly, you already didn't have to share dependencies, Linux apps could already embed unsupported system dependencies that they wanted to use, and many of them (particularly games) already did.
This makes that process easier, which you may view as a negative, but another benefit of that is that easy linking with Flatpak runtimes means applications are more likely to link to those libraries in a more inspectable way, and it's easier to at least audit the applications that were already bundling these dependencies before.
For me both systemd and flatpak have made using Linux better, so I use them and basically ignore the political debates. If something better comes along, I'll use those too!
As for me I'll keep using Flatpaks as they work great and have wide support. Alternatives are either obnoxious to use (Nix and Guix) or lacking in basic functionality (Appimages).