Some of your issues makes me wonder... i.e.:

>Beggining/end of line: Option+Left, Option+Right; high frequency of use.

on macOS you can just use the 30+ years old Unix convention of Ctrl+A and Ctrl+E to get to the beginning and end of every line everywhere in the OS.

> "apt install"

That is because no generic consumer in the world actually uses a text-based package manager. That's only the CLI users, Linux/Unix/BSD users and the like. At the same time, software distribution isn't a one-size-fits-all approach. In line with apt, on macOS there is a packaging format much like .deb and it's called .pkg. It is compressed, has a manifest, some pre/post install scripts and the actual files. The .app distribution method is much more like a snap or container, which is what the world has been moving to for decades. In one way, it's even more comparable to nix, since applications and their dependencies live in their own location independent namespace. On top of that, there used to be a package manager that actually proved apt and dpkg for macOS, but almost nobody wanted to use it because that method doesn't actually fix anything.

> There's a difference, in almost every piece of software,[..]

> OSX puts one small dot next to an icon of the app that's open. [..]

> OSX litters all the (local) directories you visit with finder preview files. [..] (<-- actually nothing to do with previewing anything)

Those three are pretty much all the same thing: preservation of state. By default, the concept is that it doesn't really matter if a piece of software is 'open' or 'running', what matters is that when a user takes an action (i.e. start browsing the web), it continues from the last state the user left it in. That is a really hard problem to solve and something Linux will probably never be able to solve due to the difference in even basic GUI SDKs like GTK, QT, WxWidgets etc. and that's not even considering X11 which is a whole different mess by itself (data exchange via atoms on window objects? wtf?) There is a setting that will undoubtedly become default where the dock will no longer show a difference between 'open' and 'closed' since the difference will pretty much be to small to be relevant (i.e. is it in the process table or not will be about as much as a difference that will be left). Currently, there are a number of frameworks in place that do almost all of this, some are purely for managing state of the UI, some are for document-based programs that offload revisions, storage etc. to the OS, some are for managing idle time (i.e. AppNap). The idea that an Application is just a binary that hooks into the UI thread to dump some pixels on the screen hasn't been a reflection of reality on macOS for about 15 years. Having this information in mind might make all of your observation a lot more sensible.

Regarding .DS_Store files: they are data files containing the settings you set for a directory. So if you don't change anything for a directory, then no .DS_Store file is made. But when you say, change to icon view, move stuff around, go to list view, and setup custom sorting orders, then the OS will store your settings inside that directory. If you then open that directory on another Mac, you will get the exact same representation (be it via network, mass storage or target mode).

> Global menus

This often boils down to taste, but regarding those studies: they were about 'how hard is it to aim', which is relevant today, even (to an extent) for touch screens. The idea is that the global menu is at the top, and if you throw your mouse pointer at the top of the screen, you are always at the global menu, no aiming required. You basically completely remove an axis of aiming from the process. You can't overshoot either as the screen simply ends there. If you take the 99% of users, this is much easier than trying to aim for a strip of pixels at a random location somewhere in the top half of your screen. On top of that, multiple menus make little sense, you can't use more than one as you can only focus one, you only have one pointer, and you can't (on any implementation i've seen) use them without losing focus of your current window. Maybe this background information alleviates some irritation ;-)

> A kernel update

There are no stand-alone kernel updates on macOS, at last not by default and not planned. The type of updates that require a reboot are pretty much always those system updates, which are run as transactions instead of copy+replace. They aren't small or as insignificant as a single package either, most of them are comparable to complete distro upgrades like FC27 to FC28. And yes, I'm talking about those point releases (i.e. 10.13.3 to 10.13.4). Just because the semver delta isn't that high doesn't mean that on the scale of operations the content doesn't have a big delta either ;-) Most of them are a few GB in size and comparable to a reinstall of the complete OS (because again, it is a single, reliable transaction). Keeping that in mind, isn't it great that this can be done in under an hour, only breaks if you have made extreme system modifications and basically doesn't touch your own user data or programs? While not-touching-anything-it-doesn't-need-to-touch is standard, just like it is on Linux packaging systems (well, most of them), doing a complete distro upgrade on the fly isn't always that easy and reliable on other operating systems. Windows mostly just fails or takes forever, on Linux distros you have to do things like 'sudo apt-get update; sudo apt-get upgrade; sudo apt-get dist-upgrade; sudo reboot;' and hope nothing broke. Same with yum and dnf, I've had simple upgrades (bare FC install upgrades) fail and leave it in an unworkable state, mostly when libc was upgraded, or kernels (and the modules failed to update in the initramfs) or when the packaging tools themselves were upgraded (when they break, good luck fixing anything).