I'll present one of the other perspectives.
I was all-Microsoft, from MS DOS up through Windows Server 2003. Late 90s MCSE, nothing but MS. Most of my time was spent building and maintaining NT4.0 installations and then migrating to 2000.
I got tired of keeping pace with the amount of changes in all of the services somewhere between Server 2003 and Server 2008 and have since jumped ship.
Now I use entirely open source software and a mix of AWS instances and dedicated servers in various parts of the country for heavy lifting. (I work with multiple small companies rather than one large company that would benefit from the perfect AWS deployment.) This is after having spent time and personally maintained dozens of machines in half a dozen different data centers stretching back to 1998.
It's going to take a hell of a lot.
Whilst I rather like FreeBSD, when I have to throw an architecture together that will survive over a decade, Microsoft wins every time. They're the only company which provides certainty. RedHat are close but their support sucks.
What was that that you got better supported from Microsoft than from Red Hat? Specifics please.
With respect to support you get a very narrow configuration of supported software and hardware with RH. Keeping it rolling isn't as easy as it looks. The developer support is awful as well. Documentation is shitty,you're tied to C++/JDK versions that are ancient etc. Also no MSDN, no partner support (which is pretty awesome). My few dealings with RedHat support have left us without a solution.
For ref - platforms: Exchange, Windows Server, IIS, SQL Server (the latter I've got an installation that has been cleanly upgraded since 1996 though TWO versions)
Hardware isn't upgraded. It's replaced when it fails. It's easier to get hardware off the shelf that is certified for Windows Server (any version!). This is particularly true on the tail end of a product lifecycle.
The OS upgrades in Linux are usually utterly painful (Debian included). If you go with CentOS/RH, you have to do this every 5 years at average due to the API churn in Linux distributions[1]. You need to get your developers on there ASAP. With Service Packs and Java updates, a simple test cycle will suffice as they don't break the API contracts. They promise this and deliver.
[1] The kernel syscall interface is fine but major versions of Apache, glibc and compilers and anything even vaguely related to client-side stuff is a PITA.
It was impossible to get that Perl web system running on anything modern without massive pain.
For the wonderful bliss of Linux-land, at least with Windows you know that something written 20 years ago will probably still work. (Yes, I know - they shouldn't have written it in Perl)
NB. The biggest issues I've seen in upgrading are modules that use C libraries (unfortunately things do change over time!).
As an example I'm still running a Perl web system & data munging backend that I wrote back in 2001 with only minor tweaks over the years for new/modern systems.
If I had known what I was doing with Perl, it might have been better. I was a bit harsh on Perl, apologies. But it still stands that migration on Linux boxes isn't massively easy or fun (not that Windows is either)
Well done Microsoft.
And the reason why you consider RH's version "bastardized" is, I assume, that it's not "the newest and latest." Which is the main argument with which we started: that RH intentionally doesn't push "newest" all the time in order to have long support cycles.
Your argument for Microsoft was that their technology changes slower, and then complain that RH technology doesn't change fast enough?
If you look at the CLR there are only two major current versions: 2.0 and 4.0 and perfect legacy compat and wide support across all windows server versions.