My hot take here is that this split exists because of the way that Linux development works differently than other Unices and other operating systems. Essentially, it's an example of Conway's Law.
As always, things are about API boundaries: what is internal to you, and what is exposed externally to your users.
With Linux, well, we all know the rms copypasta: "I'd just like to interject for a moment. What you're referring to as Linux,
is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux." This is a joke, but it also points to something real and serious: Linux, being just a kernel, means that they provide a stable kernel API. glibc, being written by a different organization, builds on top of that API and adds its own stable API.
By contrast, many other operating systems are developed as a full operating system. They don't produce a kernel as a standalone component. As such, they choose some other sort of boundary as the API for the OS. On unices, that's often the libc. On Windows, that's the Windows API, of which win32 is an example.
There are good reasons to not make the kernel your API boundary. Different systems make different choices, and that's a good thing, not a bad thing.