As others have pointed out, in reality the SDKs are very often not really shared and you end up with multiple copies. This doesn't happen (and is basically impossible) with a traditional package manager
Not sure if you've used Flatpak before, I have 108 flatpaks installed with just 3 runtimes, and one of those runtimes is for a deprecated app that won't even update for my distro anyway.
Flatpak means I can continue to use it far into the future.
I have a similar 5.7" 32 GB eMMC device that runs a debian-ish distro with Phosh GUI, where I have been installing flatpaks left and right (without caring which runtimes they use) for a reason ([0]) since early 2022.
I am now at 107 total flatpaks, 18 of which are platform packages (= 89 apps+locales). If I were to remove five outdated apps, that are archived or inactive upstream, I would be able to get rid of four platform packages (I really should, but I don't want to for sentimental reasons).
I have found things to scale similarily across devices: The more flatpak apps you use, the better the ratio gets.
If you just use one app, you may end up with 3 Platform packages for it if you are unlucky, making that one app an incredible disk space eating monster. When you have 50 flatpak apps, things will look way better.
Now, would I like to have all these as native deb, rpm, tar.xz (arch), apk? Yes.
But I would also like to use the latest version, making that pretty much a pipedream - and in some cases the distro packages (mostly on Alpine and the AUR) aren't always as functional.
I am really glad flatpak and flathub are a thing.
OT, regarding alternatives discussed in other threads:
AppImages aren't really a thing on aarch64 (also, I use Wayland, which probonopd does not seem to be a fan of [1]).
Snaps: I had 'wrong arch' failures when attempting to run what was promoted as arm64 on Snapcraft.
Oh, don't get me wrong - Flatpak is definitely better in a lot of ways than Snap or AppImage. Just let's not pretend that it doesn't eat a lot of space, because it does. It does not scale linearly with number of apps because of deduplication, sure, but you still can easily get the runtimes alone to consume more space than your whole underlying OS with a full set of apps installed natively, and for little benefit - Flatpak makes it unreasonably hard for users to switch the app runtime to a newer one even it it's perfectly compatible and could instantly free gigabytes of disk space.
I don't think app distribution should be dominated by "app store" type solutions; distro repos are an important part of the system too. But there's definitely a use case for "app stores" too and Flatpak fills that niche pretty well, although it still has some really annoying details to sort out before it can actually be as useful as it should be. Thankfully, these issues are mostly about the frontend - the backend seems rather solid already, which is great, so maybe it's just a matter of time until better frontends appear.
> I have a handful of apps and 3 flatpak runtimes on my phone right now and that's only because I'm the latter (and have to be because of 32GB eMMC).
I mean, yes Flatpak will use more disk space than everything being packaged with the distros native package format, although in larger amounts you get a better ratio.
This is the trade off that has to be paid, Linux has no stable userspace ABI like Windows (so, Microsoft doesnt need to ship multiple versions of a dll), it's already the norm in the server space with containers, where it's been extremely successful. Flatpak goes a step further than OCI by having native deduplication due to OSTree (although there is push to get this on servers too)
Do I think the trade off is outweighed by the advantages? Yes, absolutely. I have used Fedora for 10 years (currently using uBlue/Silverblue) and Flatpak makes installing things like Discord, Slack, Steam etc 10x easier on Fedora than it's ever been (partially due to no or outdated rpms).