As a user, you're missing details, and completely misunderstand several abstractions.
For instance, gtk and qt are not desktops. They're ui toolkits. Bunches of widgets that can be composed to cobble together a UI.
That's completely separate from the topic under discussion, which is mode of application delivery. FlatPak involves using namespacing and containers to "spin up" a virtual system with only visibility into those slices of the overall host needed to run the program.
This is good because it at least keeps unfamiliar software constrained somewhere predictable, but poor because often it won't use OS host libraries, which are generally kept the most up to date, and worst of all, enforces a complexity and debuggability tax where one has to have an intimate understanding of what is going on "in the box" if something goes wrong.
Other ways mentioned are the distro model, whereby distributions maintain repository ecosystems and make decisions with regard to FHS compliance, system tooling, update pipeline, etc..., and use those to support their user base.
There is the original "compile and stage it yourself" crowd, who basically concentrate on reproducible build capabilities, but tend to lack in automatic dependency resolution.
There's the Mac way, which isn't terrible. It tracks and designates places for libraries, Frameworks, and Applications, and has a lot of automated and well integrated ui-tooling which makes the user experience of software install easy, but it's just another paradigm you have to track when trying to write portable software.
There's static linking, which delivers executables that are entirely self-contained, but tend to be bigger memory footprint-wise, each have an upgrade path separate from every other executable, and benefit not at all from dynamic linked libraries on the host system.
Then finally, there is dynamically linked executables. They're small, commonly reused code is loaded once in memory you have the additional complexity of the linker to be aware of, but you can update the entire system's audience of a particular library at the same time... Which can be a double-edged sword given how the maintainer scripts the install or sets up their system/build environment.
Personally, I just sidestep the issue myself by digging into and learning about software I use on a regular basis with disassembly tools, and treat all of my systems the way a good farmer treats their livestock. Distant reverence, but with a careful eye as to whether there is something wrong, and a hard fought for willingness to kill something and start from scratch. It's the only way I've found to be truly safe and resilient in an environment where everyone optimizes for their own particular definition of convenience.
(My definition of convenience is a minimum difficulty in troubleshooting what might be wrong, so I favor fewer abstractions as that entails less Tower of Babel to wade through).
Full disclosure: my approach generally would classify me as a bit of a curmudgeon in the industry as I still approach computers as being analogs of physical machines. There is a healthy corpus that revels in abstraction, but I'm not really one of them. I like to have a ballpark understanding of what the artfully arranged beach sand is doing. Adding more abstractions or having the computer do things itself is generally not something I strive toward as it almost always comes with an unacceptable increase in the overall complexity inherent to navigating the Gulf between how I and everyone else thinks the system works and how it actually does.
More than anything else, in my experience, keeping that Gulf small leads to better overall satisfaction from a lay User. YMMV.