Linux 101 stuff. Questions are encouraged, noobs are welcome!

Flatpaks ship all the dependencies of the application (i.e. the libraries that the program uses) in a single bundle, which usually accounts for much of the size.

The upside to that is that flatpaked apps are universally compatible across distros; the downside is the file size.

Another catch to flatpaks is that they run in a sandboxed environment, and each application has its own varying levels of isolation from your main system. This can lead to unintuitive issues like not being able to see files you save in a flatpaked browser unless you save to ~/Downloads. This sandboxing does have some security benefits, but is not generally considered robust protection from malware.

Flatpak does deduplication, if two apps include the same dependencies then that's only stored once.
What this means is that the more you lean into flatpaks, the smaller the individual app footprint on your drive becomes.

The main benefit as an end user is gaining access to software that might've never ended up in the distro repository either way. And not having to worry about missing dependencies is a nice bonus.
I recommend getting Flatseal to get a nice GUI for handling flatpak permissions.

Have you ever tried to install a package and the install failed because of a missing dependency? You spend time chasing down that specific dependency, you find it and try to install it, but then the dependency itself fails to install because of a further missing dependency of its own. This is two steps into "dependency hell".

This doesn't occur with a Flatpak install because all the dependencies are baked into the Flakpak.

Primarily, it is to the app developer's advantage to use flatpak for distribution, as that lets you concentrate on getting one consistent version of your software out on an environment that is the same for everyone - the flatpak sandbox. If you use traditional methods, one of two things have to happen - you need to maintain multiple versions of your deb and/or rpm package, to cater to Ubuntu, Debian, Fedora, SuSE, and Enterprise Linux users. That didn't include Arch, Gentoo, Slackware, or from scratch source compilers. Which gets to part 2, hoping each community will make and keep up to date the source code builds themselves, because: Having source code and build environment settings for different distros to build from source and have it work in each distro, which may require or have available only certain versions of any libs you call on, that might not work with your code. This is "dependency hell", and it only gets worse the more linuxes you want to support directly.

It's a lot easier to just ship the flatpak with the dependencies in them or linked in their flatpak libs as well. One set of dependencies and one build that runs on everything.

Whoa! That's a gigantic Flatpak. I like FP because I can centrally managing app permissions with flatseal. I also like it when installing apps that have x86 libraries that I didn't want to install on my x64 only box. Not perfect, but it's nice also installing apps that only live in userspace and didn't touch my core os files. I like to to keep system and userspace separate. It's also nice to uninstall and remove everything associated. Pro-tip: try to only install flatpaks from original app devs if you can.

For me the benefit was apps actually install and work now. In previous attempts to switch to Linux in years past, I would always go back to windows due to apps not working and dependency hell. With flatpak everything just works. I also appreciate the ability to manage permissions easily, and the application data is stored in one consistent location.

4GB per app sounds extreme though. That is not my experience at all.