this is sad

If you look you'll see that they are not substantially larger then their rpm/deb equivalents if done correctly. Recently they re-did the Libreoffice snap that took the size down from ~1GiB down to 280-ish MiB or so. That is only 70-ish megs larger then equivalent rpm or deb files and even then those don't include Java, which is necessary to unlock all the Libreoffice features.

Debian's APT tool is an awesome technical solution to an important problem that few others have attempted to solve, much less successfully solve as well as Debian has. apt-get scales up to distributing and installing 5-digit numbers of packages by 3-digit numbers of developers to 8-digit numbers of users, and Debian does an admirable job of ensuring continuous service from devices running their software. I've used it while wearing developer, administrator, and end-user hats for twenty years, and for what it does, it's far superior to anything else.

The problem is that APT isn't a solution to a problem anyone not participating actively in the Debian/GNU project expects to be solved. It's a workaround at best, and it's a failure (i.e. the opposite of success) when measured against several important performance standards.

APT needs minutes of CPU time on a PC-class machine to navigate through a carefully curated (i.e. expensive and error-prone) database of packages labelled according to their dependency relationships. A single-package install on a smartphone-class machine could easily drain a fully charged battery just trying to solve the dependency graph, let alone doing all the IO to perform a non-trivial dependency upgrade.

Assuming APT doesn't finish a package install request by saying "sucks to be you, I can't figure out how to install that," the result can still be disappointing. The configuration APT generates can be specific to an individual user or server instance, which has severe QA and support implications even when it doesn't fail partway through in some disastrous way (which is a thing that happens sometimes, and must be planned for).

In order to get any sort of reproducible behavior and mitigate the technical risks, one has to create chroots and use filesystem snapshots to replicate the various possible development and runtime configurations, back out of bad install/upgrade disasters, and sometimes even to run the applications as well. This would all be worthwhile to build a unique custom setup or development prototype, but in most cases the intended result is to just run a configuration similar to some well-known template shared by thousands of users--and a monolithic binary download is a much better way to get that in practice. Once you've crossed the line and implemented containers or VMs to resolve dependency issues, APT is only useful as a dumb package downloader.

APT edits the runtime in ways that carry elevated risks of catastrophic failures (e.g. bricked device) compared to its competitors based on mostly read-only (i.e. monolithic "system" image) or logically isolated components (i.e. chrooted containers). Often the last successful interaction an end-user has with the device is answering "yes" to the question "Do you want to install this upgrade?" and that's not a story anyone wants their end-users to tell from a first-person perspective.

APT relies on its maintainers to provide a detailed catalog of all the non-trivial dependencies between packages as they are found "in the wild." Everyone else considers the wildness to be the root cause of their problems, and tries to solve that instead. They integrate dependency packages into a single domesticated whole, simplifying the dependency graph down to a handful of (possibly very large) nodes. Ruthless decisions are made to control the size of the dependency graph: we will have feature X, feature Y in the next release, feature Z is deprecated and users will be forced to upgrade or opt out of accepting future releases, no inter-package dependencies are permitted without the permission of the vendor, etc. Vendors didn't invent these strategic restrictions because they're greedy or evil--they *discovered* them, because they're trying to build products that work well enough to sell.

Using apt-get requires specialist skill, and that skill isn't getting any cheaper over the decades. Today, machines range in price from $5 to $1500, and most users' data is worth not more than $100 (thanks to ransomware vendors for researching this for us!). APT easily absorbs $1600 in support costs when something goes wrong, making it more expensive to fix than to throw away. There's no guarantee that spending $1600 will fix APT either, so throwing it away is a more predictable way to spend money.

The one advantage APT used to have was the ability to do in-place live upgrades on a server with a high probability of success. Debian used to be good at that sort of thing, but they started failing in 2008 and haven't gotten better since. If every upgrade carries the risk of a service interruption, it's both cheaper and safer for a server operator to just start over with a new machine, validate all the old applications on a completely clean install, and cut services over from the old machines at some network layer above the individual machines. This is now SOP in the industry, and it means that even if Debian and APT did still support live upgrades well, nobody needs it any more.

APT could have a place among the set of users who will spend thousands of dollars worth of their own time to upgrade a $20 router into a $200 one. There are vendors who serve those users (Raspberry Pi is especially successful here), but even these vendors tend to build monolithic device-specific images on SD cards instead of integrating their changes into the base distribution.