Personally I just build all my software so it includes its dependencies and then you don't need docker or any complex image manager. Don't rely on a bunch of crap being installed in the system path! Much much simpler this way imho.
(I get your point, but docker has made distribution way easier in a lot of ways, and you accept sole tradeoffs for that convenience)
It's so sad that running software on Linux is so wildly complicated and unreliable than things like Docker had to be invented. :(
https://www.phoronix.com/review/windows11-wsl2-zen4
wsl2 runs under the windows hypervisor as a vm, but so does windows since windows 11. So there should not be much performance issues from running stuff in windows vs wsl2. The major bottleneck is if you need to move files from and to the windows vm to the Linux vm
Why people constantly insist on adding unnecessary layers of abstraction is beyond me.
As for why to do it, if you develop on server apps Linux is the standard (as an example redis does not have a windows native version), and I say this as a developer of Windows based microsevices on the cloud, my company is actively looking to migrate to Linux due to lack of tooling in the windows space (and also licence cost of windows server), like it or not that is the way it goes. If you don't need it great for you, but for other of us those layers are life saver
So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.
It should never be more complicated than "run the binary". Running programs shouldn't require infrastructure or VMs or Docker images. Deploying a program should be, and can be, as simple as sharing a zip file, extracting, and running.
It's not that hard!
Binaries should always include the dynamic libraries they require. Docker is one way to include them. But you can also just include them the vanilla way. Works great! Very easy and reliable.
Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.
I tend to ship code that needs to run on Linux + macOS + Windows + Android. So Docker is a total non-option. And it's totally fine! Very easy in fact.
It's literally impossible to _not_ depend on the system path.
The "Linux Way" is to depend on a bunch of random garbage pooped by lord knows bullshit script into one of several global search paths. This is bad, stupid, and wrong. Programs should include as many of their dependencies as is possible.
The number of dependencies that a program can not deploy and must assume are provided by the system are extremely minimal and special case. It's a short and static list.
In general no script or program should add libraries into the global search paths. On Windows user programs do not add random crap to System32. On Linux the existence of /usr/lib is an abomination that should not exist.
Is that better? I'm fairly certain you understand what I'm trying to say.