If your distro provides everything you need then I would avoid flatpak. Getting apps to speak to each other is a pain, updates use more data, backups and restores take much longer, they don't perform as well and config files are not necessarily where you expect them to be.

I have Debian Stable on an older laptop and only install apps as flatpaks if they are not available otherwise. I also have a very new laptop with Fedora on it (because it needs a newer kernel) and have had to install more flatpaks just to make things work properly, because they include their dependencies, codecs etc which are missing in Fedora. Appimages seem to do this too and I find them preferable to flatpak because they integrate more predictably with my system. Apps are slower to launch though and have to be manually updated.

Like you, I'd prefer to just have a package manager and a single source of software and plan to go back to Debian when my newer machine is supported by it.

FLOSS used to include the ability to build software. Perhaps that's not important anymore but now a days some developers don't attend problems with their build recipes because they only consider what they release through binaries, whether on flatpak or whatever other binary repository they like. At least I dislike that, it's ok to me some or most users would prefer to grab a bloated binary rather than building anything, but that doesn't mean forgetting about those actually wanting to build from source, or wanting to use shared libraries and software from their distros, actually that's a requirement for free/libre software repositories. Not sure if the tendency is to move the gnu+linux users into app stores like the ones on windows, now ubuntu snaps, android play store and the like. Sure there's more security with sandboxing, but nothing one can't get with firejail, and if wanting MAC as well then firejail + apparmor for example.

At any rate, just my little rant. And if you're wondering, I use AUR on Artix, and I really hope I won't have a need for a flatpak stuff.

It depends a bit on perspective and use-case, really. A flatpak'd application can be a fully-featured (all dependencies bundled) package in order to be portable. However, most flatpaks you might commonly encounter don't quite do this. A good portion of the libraries may be distributed in common runtime packages. This will be the case if you use flatpaks from Flathub or Fedora. There still can be bundled libraries with vulnerabilities, but in many cases, there are basic dependencies from external, common library sets.

As far as varying dependency versions, a developer may be on a host with either newer or older dependencies than expected by the user, but as long as the developer's application (and any unique libraries) are compiled against a common runtime as previously mentioned, it does make distribution to a wide variety of distros (LTS, 6-month, and rolling alike) relatively easy.

In comparison to OCI images (the kind of images that make up Docker, Podman, and a good portion of Kubernetes container images), flatpaks are a bit less extreme. Flatpaks contain much the same kind of files and structure that a standard distro package would, but simply get sandboxed into their own environment (via bubblewrap). Additionally, flatpaks don't necessarily need system-level access for installation and usage (full userland confinement). It heavily depends on host environment and configuration, but typically OCI containers are a full, minimal, immutable filesystem structure run in a virtual environment. Not quite a virtual machine, as (in Linux anyway) they are run on the host (almost always in a sandbox) without extensive virtualization capabilities being needed. The general difference in security capabilities depends on the differences in sandboxing between a flatpak behind bubblewrap and an OCI container's runtime sandboxing. There is also the notion with OCI containers being able to run as virtualized users, including root. With OCI containers that can obtain root access and a flaw in the sandboxing of say Docker in its standard rootful mode could allow for root level processes in the sandbox to act upon the host.

From what I can think of in comparison, there is the big problem with Flatpak in that it really isn't suitable for packaging command-line applications: only GUI applications and libraries. OCI container images are often tailored for running web apps and other persistent CLI applications

I never use flatpaks and am doing just fine. I don't want my packages to be installed from a bunch of different places; I want it all managed by one package manager, which for me is my distro package manager. I've never noticed a problem arising out of not using flatpaks; everything I want is either already packaged for me, or I can make a package myself.

I'm using MX Linux AHS, it is Debian based, it is always up to date, like latest firefox a few hours after it's out, kernel 6.12.17 as of today, etc.

It has no systemd, no snap, no flatpak. It just uses the good old .deb and everything is working fine.

I like package managers just fine. I don’t want to have to have a plurality of software management tools.

Same. I grumble when I have to install things through the AUR. I'd prefer if it was in the official repos.

can continue to blissfully ignore

That's what I've been doing. I haven't run into a situation where I've needed to mess with Flatpak. 🤷 Curious to hear other folk's experiences though.

Also for your consideration, Flatpak seems to be mainly used for desktop GUI apps. You'll still need your regular package manager to install CLIs. So... if you wanna keep your software management tools to a minimum...

The risk of dependency vulnerabilities is real.

Also, flatpak packages are not digitally signed, unlike apt and all other major Linux distro package managers.

Arch based distros (except for Manjaro) has every FOSS and some proprietary software on the AUR

I mostly do. 99.9% of the software I use is a Debian package. Well on Debian anyway. I do have one AppImage.

That's what I do. But then I mostly use Arch or Arch based distros (e.g. EndeavourOS). So I have access to AUR. If something isn't on AUR (very rare, but can happen), I just create the package for it and publish to AUR. I do use some AlmaLinux machines as server. I don't really need many programs outside of the standard repos there since I use them mostly for hosting Docker images. But if I do need to install something like that, I've some self-written LURE install scripts.