Admittedly, there is an unsolved problem with reliably and repeatedly packaging and updating software in the Linux world. Snap, developed by Canonical, who makes Ubuntu, is one attempt at solving this problem.
From my understanding, Snap bundles all of an application's dependencies separately from the host system, and runs the application in a sandboxed environment. Updates to the application are handled automatically and executed by a daemon (background process) that runs a few times a day.
There are reasons for all of Snap's design decisions, and I'm sure they're useful in the right context. However, Canonical is all-in on Snaps these days to the point that many regular apt-get package installs on Ubuntu force you to install the Snap version of applications with no real supported way to avoid it.
In my original comment, I'm suggesting that the inflated size of Ubuntu installs could be partly driven by so much of the default software being Snaps now (which bundle all dependencies and therefore you inevitably end up with duplicated stuff on the machine).
I've found Snaps to be inconvenient on my personal Ubuntu devices, and dislike the way Canonical doesn't give you a choice not to use them, so I've moved on to different distros for my own use.
One of the great myths is that applications share dependencies, in practice they don't really besides a handful of libraries like libc (which snaps don't package, it's provided by the core snap).
Maybe, maybe not. I guess it depends a lot on your system and on the packages you use.
I believe that one is entitled to believe that sharing dependencies on the system is the way to go (versus bundles), and more specifically one is entitled to not like snaps themselves. In that case, it is a great idea to move away from Ubuntu and towards a system that does what one prefers.
Not the OP. But for one, last time I checked there was a Canonical lock-in with snaps. And it was not completely open source (at least the servers were not?).