I've always wondered why Linux binaries are incompatible with each other while you double click on an exe and it'll pretty much always work.
It's literally easier to run old Windows binaries on a Linux than to run old Linux binaries on Linux.
Most proper Windows applications do ship many libraries but they are often really special purpose or actually part of the application via plugin interfaces.
On Windows you don't ship the equivalent of libc, libcurl, libssl, libX.. or SDL. You don't have to deal with any of the pains in the article. Those are all in the OS and they have a stable ABI. Moreover this approach makes your binaries more secure by updating more critical points of failure (i.e. web interfaces, crypto) with the OS rather than you as the developer being forced to do so.
With many Linux distros, the expectation is that you run software from your distros maintainers which will do all the hard work of mixing and matching dependencies for you.
The trouble begins when you go outside of your distribution's supported software. Some solve this by building everything from source on unsupported platforms, others will just ship their preferred distro with their binary and run the entire thing as a container. Similar to what Windows does, except less optimised for storage.
The "old" way (putting the correct .so libraries next to your executable and using those) still works well but it's being replaced by static compilation in many newer projects.
A "Linux distribution" or "Linux OS" or whatever people install in their computers and call "Linux" is not just the kernel though, it is the kernel and a bunch of additional software and -most importantly- libraries on top of it that provide functionality the kernel itself doesn't provide. This includes stuff like getting a desktop environment, which is often made up of -among others- several dynamic libraries that provide functionality such as opening windows, providing elements like buttons, checkboxes, inputboxes, etc and of course handling graphics and user input.
Very few of these libraries however provide a stable ABI. On average, you can expect a program from the late 90s that uses the GNU C Library and X11 to work because those libraries provide stable ABIs (as long as you are not trying to abuse them and do not use undocumented features) but anything beyond becomes harder. cURL does provide a stable ABI since the 2005 and they promise not to break it, but there are very few libraries that make such promises (for many that haven't broken their ABI it seems to be more of a consequence of their development than an explicit goal). It is really up to the developers of each library to keep their ABIs stable - assuming they care of that in the first place (IME with talking with some developers, even here on Hacker News, many do not care or even seem to actively refuse to understand what the problem is in the first place).
All the above means that Linux distributions come with a lot of different libraries and library versions (so even if a binary depends on libfoo and libfoo exists on the system, it will still not work if it depends on libfoo version 1 but the system has libfoo version 2 which broke compatibility with version 1) just to provide a regular desktop environment.
On the other hand on Windows you get a ton of functionality out of the box - not just for making GUI applications, but also for networking, graphics, audio, video encoding and decoding, etc. Even if that stuff aren't the best in class, they're there and applications can simply depend on them.
More importantly, Microsoft promises to not break the Windows API ABI and that promise has held for literal decades.
In the case where an application needs more/different stuff, it doesn't need to provide everything of the above, it only needs to provide the stuff that it needs - e.g. a video encoding application can use the GUI functionality that Windows provides but still use ffmpeg for performing that encoding. While it'd be duplicating functionality that technically Windows already provides, it'd only be functionality related to encoding, not everything.
So basically, Windows applications tend to pretty much always work because they can rely on Windows to both provide a lot more functionality out of the box and remain compatible than Linux applications do.
Note that this is not a technical problem but a cultural problem - most Linux developers of libraries that would be the equivalent of parts of the Windows API that has remained stable over the decades do not believe that such backwards compatibility is important or even possible (assuming you can get them to accept that there is such a problem in the first place).