Most major Linux distros have different package managers and you download binary updates. They supply their own kernel with backports and custom compiled to stay in sync with the rest of their userland. In FreeBSD the kernel and userland are in sync so you dont have this issue.
Linux has better driver support due to more exposure to hardware.
You can go one for quite a while about how different they are, so they are very different. But you are right it is user preference.
(I excluded systemd and init to avoid a holy war)
This is true for the base system, but not necessarily true for ports / pkg. You can end up with an inconsistent pkg collection, unfortunately.
In FreeBSD at least there is a real, fully-featured, usable OS out of the box, all consistent, in one source tree at /usr/src which is quite easy to read, change, and build. Unlike most GNU/Linux distros where each random thing like "grep" is its own package developed by its own separate group of people.
Linux distros avoid this problem by separating the process of committing to an individual port/source package; building that individual package, and possibly rebuilding dependencies; and pushing out updates, which are atomic and can contain an updated library and all of its dependencies. My experience is that Linux package managers (dnf/rpm anyway) are better at catching operations that would introduce broken ABIs, as well.
In contrast, the FreeBSD ports model is to invoke poudriere periodically and rebuild all ports at once, then push the entire set out to mirrors. There is no automation that checks for ABI changes in libraries, and pkg(1) does not do a great job of confirming that a library upgrade does not break installed programs (or other libraries) via SONAME bump; much less symbol changes not reflected in SONAME.
rm -Rf /var/db/pkg/* /usr/local/* /usr/ports/distfiles/*
reboot the system and all the non OS packages (installed via ports and packages) are gone and you can start over (reboot is probably optional).
Well, this mantra is really getting old - because when people say "Linux" they almost never talk about Linux-the-kernel. Which is also why, for instance, nobody calls Android "Linux", but when referring to Ubuntu, Slackware, etc., they do.
Let's compare apples to apples: Ubuntu vs. FreeBSD.
In Ubuntu there is a kernel made by one group (the Linux project), a bunch of userland tools and C compiler made by another group (the GNU project), desktop environment made by the GNOME project, etc. etc.
Whereas FreeBSD is just FreeBSD. It is one project, in one source tree, maintained by one group of people. (The biggest exception to this is the C compiler -- it is a third-party project which gets imported into the main tree. But that's a minor thing compared to Ubuntu which does this for everything.)
I'd have probably gone with init daemons, ABIs and other core systems. Maybe mention how some of the base CLI tools differ (eg GNU has slightly different flags and rules for ordering them for `cp`, `find`, `ps`, etc).
FreeBSD is a bit of a gateway drug in that it's the most like GNU of all the BSDs. Had you use OpenBSD as your point of comparison then the differences would have been easier to describe. But ultimately you're always going to get some cross-pollination across all the POSIX platforms (eg GNU/Linux uses OpenBSD's OpenSSH; FreeBSD has a bunch of GNU tools; and all of the above platforms will run most DEs, Apache projects, etc). That's a good thing though - it was the point of POSIX.
I just wish there wasn't so many differences with syscalls - but that's moan about a very specific problem I'm having on a current hobby project.
It is, on the other hand, fully supported. Bugs in the C compiler are considered bugs in the OS and will be fixed.
I don't need a desktop environment or care about having one, so it not being part of the core OS doesn't bother me.
I'll copy-and-paste my thoughts on why I like FreeBSD from an earlier comment I made:
"Every one I have used installs the source code to the entire OS in /usr/src and make it very easy to change and recompile the system. On the BSDs I mentioned, if you don't understand how something works or you want to fix some bug, it's usually pretty easy to go find the source code, read it and learn how it works, and fix it. On most Linux-based OSs you would have to go figure out which random organization makes the component that has a bug (Linux project for the kernel, GNU for a lot of utilities, zillions of others for everything else), figure out how to download and build the source and install it into your distro (which is probably totally unsupported since your distro will expect to be using RPMs or DEBs rather than random stuff installed from tarballs...)
This is the most salient feature of the modern pc BSDs to me. It's impossible to describe how different it feels to be truly in control of your system and understand/change it however you want."
The reason I brought the DE into the equation was simply because it was being compared against Ubuntu. I don’t really think Ubuntu is the best case study there either to be honest but I’m just following on from the post that preceded me.
Or any desktop environment, for that matter, or much of everything else of any importance for the end user.