The other day, I needed a Linux machine for work. I grabbed another
NUC and put Arch on it. A vastly different experience: much more akin
to installing 7th Edition than Windows or macOS. Oh! And I missed a
step, so I had to pull some shenanigans to fix that.
Gentoo is even more arcane, but that's essentially an "I want to do everything myself" distribution. I suppose my point is that there exist a full range of distributions, from the truly masochistic Linux From Scratch to the most hands-off/static ChromeOS Flex. I don't believe that any other "OS" has such a wide range of offerings. This is obviously both a wonderful feature and a confusing nightmare, depending on your audience.
I'd put the FreeBSD install process somewhere between the two.
Sure, it's textual, but it's pretty straightforward. OpenBSD is probably
a tad closer to the Arch-like experience -- it's not as colorful -- but it's
not too hard[*]. So the experience varies across BSDs, but not that
much, while it's vastly different across Linux distributions.
I haven't installed FreeBSD or OpenBSD in many years, but I am familiar with NetBSD's text-based installer. It almost reminds me of how Solaris from the console was - if you want to you can manually set partition sizes and choose which portions of the OS you want to install, but if you just choose all of the defaults you'll almost certainly have a reasonable system. That being said, it does assume some preexisting level of Unix knowledge if you want to actually understand what is happening, or understand how/why you would want to change the defaults.
The ABI compatibility thing breaks down, too. A colleague was trying
to get the host-side of a Salae logic analyzer working on Arch, and it
doesn't. They more or less require Ubuntu 18.something, and that's
not what he runs. As far as most end-users are concerned, your
distribution of choice is "Linux", and distributions vary in all kinds of
ways.
What I think might be most confusing to the average user is that there is not really a "Linux 2" or "Linux 4" or what have you with which to advertise compatibility. Specific kernel versions are virtually meaningless to precompiled or closed-source binaries, it's all about the libraries. So you run into the situation of "we tested it on Ubuntu 18 and that works so that's what we're supporting" because it's probably not worth the time for a smaller company to validate their software against the plethora of available versions of available distributions, even if the solution might be as simple as "add this one package and it will work."
Tangentially, this reminds me of the situation with Solaris and software compatibility. For example, the Sun Workshop Compiler 6 was advertised as only being for Solaris 2.6 and up. Upon close inspection it turned out that the only reason for this was that it wanted access to snprintf() and vsnprintf(), which weren't in the 2.5.1 kernel. But it turned out that __snprintf() and __vsnprintf() were, so if you created a very simple shared library and forced it in the environment with LD_PRELOAD, everything worked just fine. Sun later appeared to wise up to this with the introduction of dependencies on internal shared library versioning.
I ran into some weird behavior in their bootstrap, though; I traced this
to something slow in the BIOS, did a fix locally, sent a bug report along
with a patch, and got told, "go use UEFI." Meh. Ok.... So I went back
and used UEFI, and the same thing was slow (unsurprising as almost
certainly the BIOS and UEFI flows share common code), wrote back,
and got silence. I pinged again the other week and still haven't heard
anything. Very discouraging. I suspect it's that kind of thing that turns
people off of at least some of the BSDs.
I've submitted patches to NetBSD and this was definitely not my experience. It's disappointing to see OpenBSD's "user hostile" stereotype borne out in reality.
-Henry