Windows' CRT setup allows for binary compatibility with older versions. You can go without if you just statically compile the dependencies into your program, but many Windows developers choose to rely on runtime versions which may or may not be shared.

MSI's biggest mistake was probably granting developers the capability of invoking any program they like. The format was originally designed similar to Linux packages. Installation steps were atomic and reversible. If something went wrong (i.e. you ran out of disk space halfway through), the installer can undo every change step by step so you can try again later without overwrite prompts. Unfortunately, adding the ability to call executables means that atomicity is usually lost.

macOS applications seem to just package every single DLL they need inside of their application folder rather than relying on the OS. I'd do the same if I were developing for macOS with how often Apple likes to make breaking changes.

The symlinking trick for .so files often breaks on Linux. Method parameters change, structs get altered, and you can quickly create working-but-unstable versions if you have a different version of the same program. The Windows way, used by Flatpak and Snap, of targetting known-good sets of libraries will work around that. The macOS way (AppImage) also works but doesn't allow for deduplication. It might, if the AppImage would be uncompressed and files would be extent-aligned on a modern file system, but in practice that won't happen.

In theory, Windows and Linux offer the same app installation flow as macOS. AppImage and huge .exe files can be moved around and deleted just as easily. Windows will let you do all kinds of things with desktop.ini, including custom folder backgrounds, and its native .iso support can offer a very similar mount-then-delete flow to .DMG files.