On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. CoreOS? Not so much -- and, yeah, I know, I could of course switch to non-systemd-infested distro, but even there, there would be at least a screen-full of processes of which I could maybe identify half?
This pattern extends to configuration: OpenBSD has a handful of very-well-documented files in /etc, whereas under Linux, things are literally all over the place, and you might even end up editing irrelevant configs, because they happen to be regenerated by yet-another-layer of tooling, or your distro is simply not using the tool you think you're configuring...
Still, I have no clear preference for one OS over the other! With workloads being mostly containerized these days, it's so easy to roll out a new VM, that the level of understanding required to, say, nurse a broken OS on physical hardware back to health, is now simply irrelevant. Just blow away the old and deploy the new, and forget about it.
On OpenBSD, the deployment tooling uses tried-and-true commands like `fdisk` and `ifconfig`, whereas for CoreOS it's YAML (pronounced: 'hell'), but the truth is... it doesn't matter that much. Getting the base OS installed, adding some volumes, creating sub-interfaces for the relevant VLANs, installing Docker(-compose), and getting the containers to (re)start is all very, very similar.
So, yeah, I sort-of get what the article is trying to say, but the ground-truth I think is that in most cases the OS isn't that much of a differentiator anymore, as they're pretty much all OK-ish...