I don't really want to argue with you but I think you're still basing this on false information or on misconceptions, I'll try to clear things up. Of course you are free to use or not use whatever packaging solution you want for whatever reason.
>All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution.
That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported.
>GTK has always had fallback stylesheets for this exact purpose
This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there.
>Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws.
Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers.
>That's more work than I have to do on every other version of every package I use
How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it.
>Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break?
No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there.
>it's really just "another competing standard" a-la XKCD
Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment.
>Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here?