Overcommit exists mostly because of fork(). fork() exists because it was the simplest possible process creation API the Unix designers could get away with, which was an important consideration on a PDP-7. Now that computers are far more capable, we no longer need to sacrifice the ability for applications to handle low memory conditions in a more useful way than crashing.
Microsoft put out an interesting PDF paper about fork():
I suspect a reputation for robustness is at least partly a self-fulfilling prophecy. People who care about robustness will be more likely to write software for an OS they believe to be robust, and that software is also more likely to be robust.
fork() + no overcommit + no OOM killer can work if you're very careful with allocations in processes that fork, but it would be a disaster on Linux. Willingness to put up with the drawbacks of Solaris is a good signal that you value robustness/stability very highly. IMO, most people developing for Linux have different priorities.
I think I agree with you, but would like to add that from reading the blog post, it sounds like Windows is actually doing this better than both Linux and Solaris (but my knowledge is a bit limited in this area).
I don't quite like the overcommit approach nor the "all address space must be reserved in swap" approach, because both can fail badly in some reasonable scenarios.
I think having a separate system call to commit/uncommit memory like Windows seems to have is probably a better approach than just having mmap()/munmap() system calls (without a way of communicating with the kernel about which parts of the allocated space you are using), because then you can have the advantages of sparse address space usage while not having the drawbacks of having the OS kill innocent processes.
This would also have the advantage that in fork(), the kernel would just need to reserve swap space for the amount of committed memory, not the amount of allocated address space, the latter of which could be much larger (by orders of magnitude).
Microsoft put out an interesting PDF paper about fork():
https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
I do not use Windows myself, but this is one thing I think they got right.