I said yesterday that both the BSD 'base system' approach and the Linux distribution 'assemblage of parts' approach to building systems each have their own advantages. One of the large scale differences between the two approaches is what winds up being relatively coherent and unified.

In the BSD approach where the base system is all developed by a single group under its own control, the base system is coherent and unified among almost all of the various parts (and exceptions tend to stick out and be awkward, like GCC). However, this internal coherence means that there's relatively less coherence across different BSDs, so FreeBSD is by now reasonably different from OpenBSD, NetBSD, and DragonflyBSD (and others), especially in the kernel. To a significant extent, having a coherent base system means not sharing parts of that base system with anyone except people who are already very close to your whole system.

In the Linux approach where the system is assembled from a disparate collection of parts, any particular Linux is far less coherent within itself simply because the parts are developed by different people, with different approaches and styles, to different priorities and standards, and so on. However, Linux shares those parts fairly widely across Linux distributions, and so Linux distributions are far more coherent with each other than the BSDs are. This sharing and reuse of parts is really why we can talk of 'Linux distributions' instead of 'Linuxes'; they are, for the most part, distributing more or less the same things assembled in more or less the same way, although with different tools, different priorities about customization and versions and updates, and so on. One Linux distribution is much more similar to most other ones than, say, FreeBSD is to NetBSD or OpenBSD.

(Some Linux distributions make different choices at various levels, including in the core C library, but distributions that go off the common path tend to wind up relatively different.)

There is no right or wrong approach here, merely different advantages and different priorities. Sometimes these priorities are necessary to get certain sorts of results; for example, OpenBSD really has to be a BSD. And people are certainly drawn to the coherence and unity of FreeBSD over the relative chaos of basically all Linuxes.

(Meanwhile, Linux probably makes it easier to experiment with alternatives to some pieces, because you don't have to sail off entirely on your own. Alpine Linux gets to reuse a lot of components that other people develop for them, from the kernel on up, while still swapping out some core pieces.)