[flagged]
I don't really care about it per se but having a cross-distro unified daemon config & supervisor, package manager, and ability to cram every single important file into a file tree (again, using the same interface to achieve this with every daemon) that has only those files in it (making backups and restores trivial) and then easily verify that I got all the important files (destroy image -> re-create, does it still look good? Then I got everything) makes everything so easy. I no longer put off trying a new service until the weekend because it'll take an unknown amount of time that could end up being hours. Odds are I can have anything available in the official Docker registry (which is approximately everything, these days) up in five minutes flat to try it out, and may not even need any further modifications for it to be ready for (personal) "production".
I use Debian but don't even care, I haven't had to touch systemd once (thank god) and the only Debian-parts I even use are its ZFS, SSH, and Docker, with my ten or so actual user-facing services all just pulled and managed via Docker, ready to transfer to any other distro seamlessly, should I ever care to. Even Samba is under Docker (oh my god it is so much easier to configure for common use-cases this way).
(I would definitely be using FreeBSD on my server if I cared about anything other than Docker, though—I haven't actually liked Linux for about fifteen years now)
And that's the thing, as I grow older I feel more and more that I just want the parts of computing that I don't want to _care_ about to be stupid simple.
If I'm doing a program needing a recent version of some language that doesn't have a FreeBSD port yet and some database behind it, I don't really want to configure it all manually because I don't particularly care for porting the runtime or managing the database (that isn't exposed to the outside world anyhow).
This is stuff where I don't want a large CI pipe or other management (or needing to remember to upgrade the packages if I upgrade the hosting OS).
Stuff like this is why "the clouds are winning", friction should be linear depending on the effort I want to put into managing something.
But going for real HW or even VPS a places an "upgrade tax" on me because I can't just let non-public services like an isolated DB just ride-along over major versions (maybe Jails with isolated userlands could be an option, but that becomes painful instead when needing newer versions of the application behind the veil).
Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different.
Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it.
Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...
For me, the difference is in do I get to compile this from sources myself or do I get someone elses compiler output?
IOW it's not comparing vastly different vehicles, but rather a vehicle with its blueprint.
Also, a long time ago it was commonly accepted that spaghetti code is awful. Docker replaces all that with spaghetti services and debugging gets much worse.
[1]: https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/...
Oh wait [1].
Portage can also do binary packages. That doesn't mean you have to have them. You can just not ever enable them and be fine.
There were operating systems before package managers and AFAICT IIRC the first package manager "repository" was a stack of floppies.
But yes, there's always a choice to be made. Docker could separate out the image repository elsewhere. It could integrate buildroot. It could use a suitable initramfs generator. I'm not sure why present day devs like to create a hodgepodge of different distros mashed together and even do it all from CI, while the same CI could also run gmake on a source tree.
For a sysadmin, docker would be fine. For a programmer, dealing with binary blobs all day, that's IMNSHO not what programming should be about.