Well, in Windows and MacOS you need libraries like kernel32.dll etc to sit in-between userland and kernel because the kernel ABI is not stable, like Linux.
Also, Linus talks about this sort of exception in his post: "unless it's some very core library used by a lot of things (ie particularly things like GUI libraries like gnome or Qt or similar)".
Even desktop libraries are moving towards IPC architectures so not even they require dynamic linking. E.g you don't dynlink a library for the trashcan subsystem, you communicate with some service on the dbus thingy. This makes hot updates possible which you don't get with dynamic linking.
Demo scene windows programs essentially revolve around the fact there is an enormous amount built in to windows that can be relied on. You can make a tiny windows GUI binary that is a few kilobytes and has no dependencies other than what comes with windows.
GUI is something like an API, let's take React Native - you just have an api to rendering (via bridge), same for X server, same for almost any GUI framework.
This is a very very tiny part of an app. UI libraries with prebuilt controls are already almost always bundled with apps.
Its not all the windows libraries, but often the OS creates just one interface library to wrap the syscalls. Those do not tend to be big libraries where you should worry about being statically linked to your program.
The problem with Linux also have to do with license, giving GPL can get some program into trouble by statically linking GPL code.
There are 3 cases for me that can force one to use shared libraries: Licensing, Dynamic loading a DSO at runtime (like in Apache modules) and when you are developing a big project, but once you need to ship the production code, get it back to statically linking everything.
Other from that i don't see why you would want this.
I'm not sure that I would want all of Windows libraries to be statically linked to all my applications.
Sometimes you want static linking - sometimes you don't.