"Been around for a long time" - yes, but that doesn't mean hair-pulling will not result from upgrading emacs and having files in .emacs stop working. (I have a very simple vim configuration so I never had a problem there, I don't know if it's because they break less or because I depend on less.)
As to easily switching... erm... just the other day I fixed a script bundled with a hardware system costing around $1M/year to lease to use basename instead of /bin/basename because I wanted to run it, not on RHEL but on Ubuntu and the latter put basename in /usr/bin. Hell, even #!/bin/env bash will break because on another system it's #!/usr/bin/env!! Other scripts did not run because ksh was not installed. At other times scripts break because /bin/sh is (wrongly) assumed to be bash but Ubuntu uses dash, whatever that is.
And this goes from trivial stuff like the above all the way down to gdb being broken by a kernel upgrade to a minor version, or kernel memory leaks caused by minor upgrades, or NFS-related kernel panics.
As to "yet not obsolete" - only if you use the box as a server needing nothing but a CPU, some RAM, an Ethernet connection and some media to boot and serve files from. Try running or compiling an old KDevelop on a new Ubuntu or vice versa and tell me if it's "surprisingly long life yet not obsolete". Also I can assure you that most of my complaints about breakage are met, if the person is a Linux aficionado, with bewilderment at my desire to run such ancient software where "ancient" means "6-12 months old". Certainly the only part of Linux which gives a shit about compatibility is the kernel (you can still run statically linked binaries from 1993), however it doesn't help much because every userspace program outside the very useful but rather limited set of the original Unix tools (grep etc.) happily breaks compatibility at every turn.
I have to say that Windows has far less variants and far less incompatibilities between variants than *nix, so you switch both more smoothly and less often in my experience. This is not to say that it's a lovely experience, just that it's not nearly as terrible as Linux.
I think you're both finding different things to appreciate and dislike when comparing Unix-like systems to Windows.
Unix-like systems really are relatively stable, in terms of, once you get it working, it will generally continue to work. And, for the majority of superficial commands you might want to run -- ps, top, uptime, w, tcpdump, vi, pico, nano, mail, etc. -- there haven't been many big changes for decades. Somebody that was pretty handy with BSD or Linux in 1995 could still find their way around the commandline on most systems today. They'd have to figure out newer init systems and a few other things, and the popular windowing environments have changed a lot, but basic CLI stuff is pretty stable.
But you're right, trying to get these systems to work in the first place, or trying to keep them up to date without incurring significant cost or downtime, can really be a pain. I've experienced the same. I think the worst offender to date was Samba; at one time, Samba 3 could do file shares with Winbios authentication but not talk ActiveDirectory, and Samba 4 could talk ActiveDirectory but not do file shares (or some such thing, it's been a few years), and they were both being released at the same time, so if you wanted a Samba server in an SBS 2008 environment you had to run both -- on two different systems. And configuring either one of them successfully was an absolute nightmare. I still have a text file under my Documents/sysadmin/ directory that has some shorthand notes on troubleshooting Samba installations and that thing is a gold mine. Every couple of years, after I've forgotten everything about Samba, I get a call to fix one that's not working. I'd never be able to do it without those notes.
That's just one example; I've had lots of issues with Network Manager ("Network Mangler"), print drivers that require 32-bit OS support which, once installed, completely bones other software updates and installations; OS updates that irreversibly break a working Apache installation (that one required me to pull a 24-hour shift building a new server), and yes, trouble with systemd/journald. All kinds of fun stuff.
It's a mixed bag. Windows-based systems usually just work, as long as you throw expensive enough hardware at them. They either do a job or they don't. But they aren't very fixable. There's no advanced logging system in the Windows environment, so whether you have any logs to work with in the event of trouble is entirely up to the individual software vendor, error messages are opaque, and I can't just go grep some source code to try to figure out what the hey is going on. Linux and BSD systems are a lot more fixable, I generally prefer working on them, but they have some of the worst quirky little bugs caused by software affecting other software, and documentation still leaves a lot to be desired.
I wonder if that makes unix-likes so resilient is that at its core it is not a tool, but a toolbox.
If one look into a physical toolbox, many of the tools have not changed for generations. Heck, the basic hammer is likely as old as civilization itself.
Thing is that these tools can be combined as the user see fit at time of usage, even it if would freak out the original designer.
Upon writing this i find myself reminded of a Star Trek TNG episode where they have one of the designers of the Enterprise on board, and La Forge is giving her a tour.
She keeps pointing out way they are "doing it wrong" until they have a situation that falls completely outside of design anticipations, and they have to create a solution on the fly.
After that La Forge gives her a explanation about how in the field things rarely work as they do on the drawing board, in particular when millions of light years from the nearest space dock.
As such i think unix-likes are resilient because at its core it was made for admins by admins. It was made to work in the day when you didn't have the net to reach out to for solutions, nor another computer to work on to create the tools to fix what is broken.
One of the horrors of modernity is that we keep forgetting or ignoring how our present lives got bootstrapped in the first place. The kind of A boots B that Boots C that replace A type catch-22.
As to easily switching... erm... just the other day I fixed a script bundled with a hardware system costing around $1M/year to lease to use basename instead of /bin/basename because I wanted to run it, not on RHEL but on Ubuntu and the latter put basename in /usr/bin. Hell, even #!/bin/env bash will break because on another system it's #!/usr/bin/env!! Other scripts did not run because ksh was not installed. At other times scripts break because /bin/sh is (wrongly) assumed to be bash but Ubuntu uses dash, whatever that is.
And this goes from trivial stuff like the above all the way down to gdb being broken by a kernel upgrade to a minor version, or kernel memory leaks caused by minor upgrades, or NFS-related kernel panics.
As to "yet not obsolete" - only if you use the box as a server needing nothing but a CPU, some RAM, an Ethernet connection and some media to boot and serve files from. Try running or compiling an old KDevelop on a new Ubuntu or vice versa and tell me if it's "surprisingly long life yet not obsolete". Also I can assure you that most of my complaints about breakage are met, if the person is a Linux aficionado, with bewilderment at my desire to run such ancient software where "ancient" means "6-12 months old". Certainly the only part of Linux which gives a shit about compatibility is the kernel (you can still run statically linked binaries from 1993), however it doesn't help much because every userspace program outside the very useful but rather limited set of the original Unix tools (grep etc.) happily breaks compatibility at every turn.
I have to say that Windows has far less variants and far less incompatibilities between variants than *nix, so you switch both more smoothly and less often in my experience. This is not to say that it's a lovely experience, just that it's not nearly as terrible as Linux.