I'm in the camp of thinking Flatpaks are definitely the future for GUI applications. While there are definitely cons...
CLI applications are not feasible as Flatpaks. This isn't what Flatpak is designed for, standard package management will still be needed here.
Dependency duplication wastes storage space, but I'm personally willing to give up a couple GBs for the benefits I get.
Developers might package their application incorrectly. This is possible, but it hasn't caused any notable issues for me in the 2 years that I've been primarily using Flatpaks.
As far as I'm aware, Flatpak doesn't have a way to allow applications to set udev rules. This generally doesn't matter, but for something like Steam Input, you will need to install the steam-devices package or setup udev rules manually so it can manage your controllers. Google's Android Flash Tool also doesn't work out of the box in the Chrome Flatpak last I checked.
...The pros more than outweigh these (in my opinion at least).
Non-distro-specific packaging means you can use Flatpaks on whatever distro you want. You can have more up-to-date applications on stable distros like Debian, or on smaller distros that don't have the resources to package every application possible. Rather than Red Hat spending a significant amount of time packaging LibreOffice for RHEL/Fedora, they can just rely on the Flatpak and spend time on more important elements of the distro itself. There's also Bottles, which enters dependency hell if packaged incorrectly, they had a blog post about this a while ago.
Application files are stored in one place in ~/.var/app. For some apps this doesn't matter, but it keeps applications like Steam from cluttering up your home directory with random game saves and other garbage. This also makes backups easier since you already know where all applications keep their files.
It makes immutable distros actually usable, which I believe will be the future for some use cases.
Permissions management. Even if no one is setting privileges for their applications correctly right now, having the groundwork for this in place will be important if more proprietary applications are going to be ported to Linux in the future.
Having to prefix commands with "flatpak run org.whoever.whatever..." gets old quickly, and setting aliases to get around it isn't user friendly. It's certainly possible, it's just not practical (which may have been a better word to use than "feasable" in my first comment).
100% agree. Snaps are kind of neat for server stuff (easiest setup of Nextcloud I've ever done, even though I switched to Docker in the end), but man the desktop experience is god awful.
I had to setup an Ubuntu VM at work to run something I couldn't do on the Windows host, I tried to open Firefox and it took ages to start. I literally began trying to troubleshoot why it wasn't opening before it finally started. Completely unusable and I have no idea why Canonical thinks this is an actual competitor to Flatpak.
Will Flatpak and Snap replace desktop Linux native apps? (www.theregister.com)
Actually, the better question is: When will they replace most desktop Linux programs?