I'll try to take this from the top. You asked a rather involved question, which needs answers from several different sets of knowledge.
First off, the Raspberry Pi uses a vastly different CPU than a regular desktop or laptop computer would. A desktop machine uses what is known as an x86 processor, running a very old instruction set back from when Intel first started making CPUs (it's based on the numbering scheme used for those CPUs back then, although the scheme has changed since).
x86 is a complex instruction set, where operations can perform very complex tasks slowly and with varying times of completion (stuff like "capitalize a string" might be a single instruction, but takes a while depending on the length of the string).
ARM is both the name of the company that licenses the CPU designs used in, among other things, the Raspberry Pi, and also the name of the instruction set used on those CPUs. ARM is a reduced instruction set language, and each instruction is designed to complete in 1-2 processor cycles, with a few other caveats I won't go into here. A string capitalization program would need to be written
while index nonzero, compare numeric range and subtract 32 if in range, which is much more complex than the hypothetical single instruction an x86 device may have.
The end result is that "Linux" for a desktop won't run on a Raspberry Pi since the instruction sets are very different (there are ways, but you'd need to emulate it or port the code anyway). Fortunately, there exist versions of Debian and Ubuntu (popular "Linux" OS builds) that are compiled for ARM.
The next issue was that, all those years ago (and I feel old now), the original Pi computers had ARM hard-float version 6. That particular ARM CPU did not have support in any OS at the time (I forget if it wouldn't work or if the hard-float bit wasn't used, but at minimum the performance would have been poor if it worked at all). Raspbian was thus compiled from scratch specifically for the Raspberry Pi (and was partially a community effort at first, IIRC). Thus there was a legitimate reason to create another competing OS.
With the Pi 2, a new CPU was used that was ARM HF v7, which meant that it now supported other OSes out of the box without the need for the Pi Foundation to distribute them, but they kept doing so for two reasons:
- It was what people were used to. People could get an OS already set up to use the Pi's boot system and drivers and desktop customizations and low RAM/CPU use, and wouldn't want to lose that.
- There are still reasons to maintain their own OS even if mainstream ones support that CPU now.
You may have already guessed what those reasons are:
Existing desktops have more RAM and faster CPUs (although this doesn't map perfectly to ARM systems since the philosophy is different, so slower ARM devices are less horrible than they initially sound), so designing for more limited systems is important.
(LXDE--Light X Desktop Environment (and later Pixel Desktop) were used for the desktop. Although I heard Pixel got binned after a while, so I'm not sure what they're using now.)
Embedded GPUs often use OpenGL ES in place of OpenGL for graphics interfacing (and are thus incompatible), so you'd need to recompile any programs that use the GPU heavily to have proper support if the Pi Foundation didn't do it for you (it's usually just a build flag since the developers added support already, so it's not too difficult per program, but you have to be sure to get them all and their dependencies).
(Custom compile QT, Chromium, Firefox, VLC and Totem (video player), etc...)
Note: The Pi is actually in the better side of this situation, since its community has successfully reverse-engineered the GPU driver it uses to have an open-source option. For other systems, especially those with a Mali GPU (also made by ARM), the kernel also needs modification (on top of compiling it for that device) by the device maker to include the closed-source drivers for the GPU, since Linus refuses to allow that sort of thing near his free-software code (for good reason). Worse, if the GPU provider then stops providing blobs for your GPU/X Server (more on that later/Kernel, you can't use (accelerated) graphics anymore on that device, so other boards can be quite dangerous in the long-term support category.
ARM systems are again, embedded, so the boot process is more tightly integrated and has less overhead (Please note: This is an abstraction, and partially from memory, on top of the fact that some of these details simply aren't public knowledge, so the best we can do is read between the lines. It should illustrate the differences, though):
For reference, x86 has a boot ROM which points at a flash chip that stores the BIOS in binary form (the BIOS is specific to manufacturer, model of motherboard, and sometimes revision of motherboard), which loads up a bunch of drivers and starts the CPU and RAM along with the rest of the hardware (Note that this somehow applies to even interchangeable things like keyboards, hard drives, and even different CPUs and RAM, despite the fact that one would think the maker of the motherboard wouldn't know any of those specifics) before looking through any attached storage devices for a bootable partition. The BIOS would then hand over control to the OS. (Now we have UEFI, which is even more complicated, since it can configure these sorts of things and talk to the OS even while that's running, or get features added to it by the OS or things you install!) (Note that this information is genericized, since the BIOS is often secret and varies by manufacturer. I still find it weird that it's published by the maker of the motherboard and not, say, Intel. Instead Intel sends the manufacturer things to update and makes them do it.)
In the specific case of the Raspberry Pi, the CPU's boot ROM (hard-programmed by the Pi foundation--it's programmable, but only once, and only with secret tools) looks through the SD card for a FAT-formatted filesystem. This then contains a number of secret binary blobs that contain boot code for the GPU in the Raspberry Pi. The GPU then boots the CPU, which then reads more blobs and starts the RAM and other systems.
(Note that this is unique for the Raspberry Pi; other single-board computers (SBCs) use yet again different boot procedures that are often also much more difficult to set up. The Odroid boards, of which I used to have one, use several binary blobs written directly to the raw storage of the SD card outside the filesystem itself, most of which were cryptographically signed by either Samsung or Odroid itself up to the U-Boot loader that launched the kernel (and the boot was done by a specific CPU core rather than the GPU). This signing prevented the user from even attempting to reverse-engineer or substitute them with open-sourced versions. Admittedly, the Pi's boot process is also closed-source up until it hits the Linux kernel, but there was at least an effort to reverse engineer parts of it for a while.)
Things in the Pi are complicated by the fact that there have been at least four different designs and architectures of CPU across its current lifespan. The method I described was for the original. The Pi 2 and 3 use different boot files than the Pi 1, marked with a 7 in the name. The later Pi 3s have an exposed bit in the boot ROM that can be changed (once) by the user to set a different boot device, but USB boot (from a USB drive) may still not work on some or all (not sure which) B revisions.
The Pi 4 starts its boot process more like how an x86 machine does. It has a boot ROM containing firmware for the first-stage GPU boot and that initializes the RAM (although there's still no user interface like how a UEFI or BIOS might provide). The CPU then takes over the boot from one of: SPI (presumably a flash chip, and possibly the same one), SD card, an eMMC flash, or a USB disk, all of which can be selected by the user or even set to have a priority order now. There is also a second onboard flash chip that contains a different set of firmware that's used to control the integrated USB hub/ethernet port chip (again, presumably to allow for USB boot and because it's more complicated now--which says something; the old USB drivers were said to be complicated). The Pi Foundation has released several updates for both of these as issues are discovered or features are added. This information in particular I've had to intuit from other documentation; more info has since been published, but many of the details are still secret, and I'm still not sure if the USB driver has a separate flash chip or if it's shared with the bootloader.
Lastly, there are also a number of special programs included in Raspbian. There used to be a special store where you could buy and sell programs made for the Pi, there's a GPIO library (actually several for various languages), there are various examples, and companies have provided "free" versions of their programs as long as they are used on the Pi. This includes the Wolfram and Mathematica languages, Java, and a VLC server library that's nice to use but closed source and normally paid-for. I am suspecting that this was permitted as a way to encourage people to purchase the full version, since there's only so much that can be done on a small and slow computer, which the Pi still is at the end of the day (and by then you're hooked on that language or program). Since the instruction set used on the CPU is so different, there's not even an easy way to try to copy the programs to another computer (which is aside from the legal issues that also say you can't, of course).
Lastly (I mean it this time) there are also a number of programs and kernel modules added for HAT and additional hardware support that other OSes would simply not have. For instance, the PoE HAT talks to the kernel's temperature sensor to decide when to turn on the attached fan. It also contains additional configuration information to tell the kernel about itself and how much power is available.
Now, your second question is about KDE, and in fact your first question is related to this when you asked what Linux is.
Technically, Linux is the kernel used by "Linux" operating systems. The kernel doesn't do much for the user on its own (it actually does a lot, but not that you'd notice it doing that). The kernel handles filesystem and hardware access and abstraction, enables multitasking, allocates memory and queues disk access for best speed of things you do, and much more, but at almost no point do you actually use the kernel itself directly while you're using a computer.
That job falls to all the programs and system program and services ("daemons" in Linux parlance; services is the Windows term) to handle. These are the libraries that a programmer might call to open a file or allocate memory. Some are also things like the compiler or text editor or command line and shell.
Finally, you have the things you interact with directly. That would again be the shell (or desktop environment*, if you like to have a GUI) and your file managers and web browsers and IDEs and so on. These are usually programs or scripts of their own that were designed to use the system programs (which themselves talk to the kernel).
(*The desktop manager and desktop environment are how you interact with the computer graphically. All desktops were built on the X server, much like how these OSes are built on Linux, but an alternative called Wayland is gaining popularity. The desktop environment can control how you sign in (though the manager is involved too for that one), what the default icons/sliders/buttons/cursors look like (through the icon theme), how you launch programs and how running programs appear and are listed, how you adjust system settings like screen brightness, size, and audio volume, and even how icons and your desktop itself are displayed. I'm told that a site called distrotest.net will let you try different builds and desktops out, if you are curious how they look.)
All of these programs other than the kernel are chosen by the group that makes a "Linux" OS. Most of the command line tools then and now are made by a group called GNU that started and promotes the free software movement. They also make a large number of the graphical tools that you'd use in Debian or Ubuntu, and a desktop environment called Gnome.
KDE is a group that creates the KDE/Kubuntu OS and that uses the Plasma desktop environment. They also make a large number of their own graphical tools that I personally feel are superior to the GNU ones (I think that the GNU versions feel plasticky and are too inflexible, which I suspect is increasing influence from the mobile market).
Since a comment mentioned Arch, I will note that its system tools are also different from what Debian/Ubuntu/KDE use. While you can try KDE and it's still similar to Raspbian, for instance, Arch would require you to re-learn some things.
The shorter answer to your question is that Raspbian is "yet another OS," but one that's also been modified to work with the Raspberry Pi. Even other OSes for the Raspberry Pi have to have those same modifications installed to work with the Raspberry Pi's limited resources, boot system, graphics, and CPU type. ARM also hardcodes things that x86 wouldn't, so each OS must also be written to tell the OS how much RAM it has and where hardware devices are.
This means that single-board computers commonly have their own "Custom OS" to easily deliver all those customizations to the end user, even if it's otherwise stock Ubuntu or Debian (which Raspbian isn't anyway, since it includes all those other programs and libraries). This is also visible in how the OS is installed.
For a PC, you would use an installer image, which is often shipped as an ISO and written to a disk, flash drive, or DVD. This then installs a "generic" OS and kernel to your computer and may install additional drivers, although the programs and core kernel are always identical. You'd then also tell the BIOS or UEFI to boot the disk it was installed to (which can sometimes be a done by the installer).
This generic approach would not even boot for a SBC, since each has different methods, and it certainly wouldn't install all the other things that need to be customized. The Pi's OS is thus directly written to the disk it's to be installed in, and is shipped as a disk image. That fact has thus promoted the use of Raspbian, and other SBC-makers have adopted the practice for much the same reason (and also because it's popularized by the Pi's success).
Again, NOOBS is an outlier. Because the Pi, specifically, performs its entire boot process from a filesystem, it can load an OS installer/bootloader/OS selector combo (still built for the Pi specifically, though) from the SD card that will finish the setup for you.