Regardless of whether C is better or not, it is (mostly) portable, which assembly isn't. This allows a system such as Unix (and it's derivatives such as FreeBSD or Linux), or OS-9 (the old 6809 and 68000 operating system, not the version of Mac System from the 1990s), or several others, to be reimplemented on new hardware platforms (such as ARM for tablets and smartphones) far faster and easier than one that would have to be re-written from scratch in that CPU's assembly language.
Furthermore, while the individual instructions in assembly language are far simpler to use and understand (for some people, anyway), they require a
lot more effort put into expressing any given construct, and that complexity increases almost exponentially with the complexity of the data structures being used.
More to the point, here, is that the majority of example code already written is written in C, mainly because most programmers find it easier to
read C than the read assembly, and more programmers know C or related languages such as C++ (or, going a bit further afield, Java and C#).
Regardless of whether you write your code in C, or assembly, or
any other suitable language, you really need to be able to read C code in order to study OS design.
Finally, most of the bloat you complain about has nothing to do with the programming language - a good C compiler (which admittedly, neither GCC nor VC++ count as) will produce better machine code than all but the best assembly coders, and do so more consistently than any human being is capable of doing. The bloat is in all the added features and support systems: the GUI (or rather, in the chrome that has been getting stuffed into them over the past several years - the original MacOS GUI ran in about 96K of the system's 128K, though admittedly the Quickdraw toolkit in the 64K system ROM was in fact written in assembly language); in the network code (when sockets were added to the Unix kernel in the early 1980s, it more than doubled the kernel size!); in providing the application developers a 'rich' system API; in the vast 'backwards-compatibilty' code that they need to provide for the 0.001% of the users who needed it (which IIUC accounts for maybe 25% of the Windows system image); in supporting drivers for tens of thousands of different CPU models, motherboard models, and peripherals; and so forth.
It is notable that the Version 6 Unix kernel described in
Lions' Commentary on the Unix Kernel (circa 1976) ran in less than 16K (IIRC), and that was after it expanded substantially from the previous version. The
xv6 reimplementation is somewhat larger, due to the differences in hardware, but it is still far smaller than some assembly-language operating systems.