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.
GUI "variety"? Are you joking? The very reason there exists so much "variety" is that they all suck. Windows has one GUI system and it's worked darn well for quite a long time, and will continue to do so. Linux might be able to let you make your windows do somersaults so you can show off to your friends, but it still hasn't been able to get the basics right, like focus-stealing prevention. Windows is miles ahead of Linux on GUI -- if there's one thing I can tell you for sure, it's that.
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.
"miles ahead of Windows for research"
For example, only 2 of the currently fastest 500 super computers run Windows and 1 of them is owned by Microsoft. All of the others run Linux or Unix.
"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.
And shells are indeed REPLs (in the sense that they run a loop in which they read, evaluate, and print things).
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).
Compared with what I know from Xerox PARC documentation and what I self experienced in Oberon and Visual Works Smalltalk, shells are like REPLs yes, but not quite.
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.
As a current Ubuntu user, I think you are just spreading old, outdated FUD.
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.
Ehhh....that's "installer downloading and executing", which is a far cry from "package management". Notably, it doesn't provide dependency resolution (which is 90% of a package manager's job, IMO), and Windows' software packaging conventions don't really work well for an apt-like system, since they are intended to be mostly self-contained outside of shared frameworks.
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.
Package management covers this, but is too understated: many of the applications that researchers use are downright hard to get working on Windows--particularly if you require any customization. I've run into this in a maddening way when working with geospatial tools. Need custom OGR/GDAL support? Prepare to spend hours figuring out how to make it work with Windows. Some deal to a lesser extent with R. Amount of time spent on edge cases is Windows > Mac > Linux. I use a Mac, but every time I build up an R environment with lots of library dependencies on Linux, I find myself saying, "well, that was easier than I expected." Conversely, when I use Windows, I'm right back to fighting library dependencies.
Windows makes simple things easy, but complex things nearly intractable.
In my experience a lot of this isn't becuase it can't work on windows, but because the developer didn't take the time to make it work on Windows. I also had my fair share on build and dependency problems on Linux when wanting something custom.
I think this is much more a ecosystem thing than a systems thing. Which do count of course.
