Just off the top of my head: package management, live-cd functionality, architecture support, command-line interfaces, GUI variety, kernel customization, scaling to low-powered harware, licencing.
And Linux is "miles ahead of Windows for research because of its command-line interfaces"? Really? Since when are 25-year-old command-line shells research products? Not to mention stuff like http://mywiki.wooledge.org/BashPitfalls
As for package management, when it works it works, but sometimes I wish it could burn in hell. I can't tell you how many times I've run into problems getting packages to work because their dependencies were either (1) no longer available ("sorry! our servers changed, your version of Linux is outdated"), (2) only available in source code form (but good luck compiling it!), or (3) not available for my version ("sorry, this version is too new for your OS"), among other things. Distributing your dependencies along with your application might not be sound engineering practice, but it sure as hell can make things actually work out of the box so you can focus on what you actually want to do.
"Since when are 25-year-old command-line shells research products?" The shell is a researcher's best friend as they have always been (and will be for the foreseeable future) the direct interface between data and the user. I honestly can't think of a faster and easier way to parse a nasty 10GB log file from a simulation than bash. The fact that its old and still in use is a testament to its usefulness.
Though to be fair, REPLs for languages like MATLAB or Julia are likely far more useful from a scientific standpoint than a typical shell (which is more useful for system administration).
It is a very different experience when the shell (e.g. Transcript in Smalltalk) is capable of interacting with the whole OS.
For example in Cedar, which Oberon copied, any public function/procedure exported by dynamic libraries can be used in the shell via modulename.function.
Depending on their signature they act on REPL text input, the active selected graphical element or some other OS element.
While this can kind of be emulated on an UNIX shell, it breaks down that there isn't an OS wide standard API to bring everything together.
Example? I could show you thousands of issues on windows where a window has stolen focus and it wasn't prevented[0]
In the meantime, it seems to me you've already conceded that Linux can't get it right, so I'm glad we agree there.
The GUI works and it is in fact just as good as Win8 (which I dualboot). When using virtual desktops, it's far better, and makes me more productive.
The package management is amazing. Chocolatey sucks in comparison.
What I fail to see, is what these basic computer functions have to do with research.
Visual Studio has a lot to do with research, and it is a fantastic tool in its own right. The GDB debugger is a piece of ancient garbage in comparison to VS debugger.
You could have focused on the real issues instead of your uninformed outdated FUD.
I use chocolatey, but it's not anywhere near the level of apt-get. That's more Windows and Windows developers' fault than chocolatey's though. They've done a great job given what they have to work with.
Windows makes simple things easy, but complex things nearly intractable.
I think this is much more a ecosystem thing than a systems thing. Which do count of course.