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.
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.
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.
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.
"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.
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.
For my purposes Linux is dead simple to use, well documented (most of the time), and does exactly what I need it to do which is to stay the hell out of the way while I burn cycles on real work.
Basically, Windows for scientific software is as bad as Linux was for 3D FPS gaming fifteen years ago. Just ask anyone who has tried compiling anything scientific under Cygwin.
And don't get me started on MS's own compilers. They STILL don't support C99, a sixteen year old standard for one of the most important programming languages!
And yes, lots of data aquisition stuff is Windows only, particularly the stuff that gets sold along instruments. But then, in that category, the trend seems to be requiring a (preferrably air-gapped) PC running XP. I've even seen stuff running only on Win98 still in use, and I've seen software for rheometers that is STILL distributed on 3.5" floppies. And don't get me started on the "needs-crypto-usb-dongle-to-function" stuff - someone should really tell them that the $300k instrument is a sufficient protection against software piracy.
I kind of gave on Linux a couple of years ago when at the same time when Apple had totally neglected the Mac Pro all you could find from the Linux community was how cool the latest 3D effects on the desktop where and chromium was much better than Firefox. Trying instead finding something like say a 2D library more modern than Cairo and there's a deafening silence.
Yes, I'm exaggerating a bit and there is some good developments. Like CERN making waves in electronics by hacking on KiCad. Though I'm sure they would be happier if they could replace Wx with something more modern, which I'm not sure the current alternatives are.
Also, when you start getting into scientific software, very few projects explicitly state "Runs best on Linux" even though that may be the case. If you are looking for examples though, I will give some: PETSc/Elemental/Trilinos/etc Clawpack/PyClaw/OpenFOAM/etc Gromacs/NAMD/HOOMD/Quantum Espresso/etc Julia/Nimrod/etc Paraview/VisIt/VMD/etc OpenMPI/MPICH/MVAPICH/etc ImageJ/Fiji/etc GNU Radio/RTL-SDR/etc
There's tons of it out there!
I think the reason why the top 500 HPC clusters are using linux is the price of the operating system and not the functionality.
1. Access to hardware performance counters and energy counters
2. Easily loadable custom drivers
3. File system that is not slow as hell ("Getting the modification time of a file ... seems to be about 100 times slower on Windows than it is on Linux"[1])
4. Practical mechanism to allocate large pages
5. Futex
In the ecosystem:
1. Package manager
2. C99 compiler
3. POSIX environment (a lot of scientific libraries and tools depend on it)
Networking is another. Windows at least used to have a bunch of different crippleware SKUs with differing networking abilities
Filesystems, Linux supports tons of them out of the box.