Sure, but static linking isn't dynamic linking. Pretending that it is has done much harm, but I don't think it's led to demonstrable benefits. If you want to split a single module into two dynamically-linked parts, you need to define the interface between these parts anyway for versioning purposes. If you're doing that work anyway, it's not hard to add export tags at the same time.

You're right, though, about history being a factor. Windows was born with dynamic linking; shared libraries were a Unix bolt-on. (Then again, symlink was a bolt-on feature too, but it's well-integrated these days.)

It's also interesting to note that on Windows, there's no such thing as a static executable in the sense you might have one in Unix. Every system call must go through ntdll.dll or it'll stop working on the next major upgrade, which will scramble the system call numbers. On Windows, the ABI compatibility boundary is ntdll/kernel32/user32/etc., while on Unix, the ABI boundary is the kernel-userspace boundary.

The Windows way of doing it is much better. It places fewer constraints on the kernel and lets you implement 32-bit-to-64-bit system call thunks entirely in userspace, completely avoiding a major class of security vulnerability.