I would certainly hope that anyone who calls themselves a C programmer would understand a very common idiom such as Bellard's ...
while (*p && *p++ != '\n')
continue;
... at a glance.
To understand ≠ to recognize at a glance. This is where a descriptive comment provides the latter, giving the reader the correct context to immediately understand the code
correctly.
The problem is, whenever you see code like that that relies on side effects like post-increment after the test, you can never know whether it is as intended or an error. The comment fixes that. The same goes for all other idioms in all programming languages.
To those who do not immediately recognize the idiom, consider the following:
/* Skip to next line, but stopping at end of string. */
while (*p && *p++ != '\n')
continue /* or Nothing */ ;
See how your mind takes a different approach when seeing both the code and the comment, compared to seeing only the code?
I've actually worked at a place that [...] had the rule "No comments except possibly one before a function explaining the purpose of the function".
Sounds like a footgun factory to me.
Linux is too bloated
Yes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.
As others have mentioned, a microkernel (with the same range of features supported) would probably be even larger. You see, just adding the interfaces for optional modules to be compiled in or omitted requires code and data structures, and this applies more to microkernels than monolithic kernels (but it does apply to all code, just varies by degree). A good example of this is the
Smoothieware firmware for CNC and G-code devices running on LPC17xx/ARM Cortex M3. It uses (GCC) C++ classes to modularize the firmware, simpler (no privilege boundaries, only namespace boundaries) but conceptually similar to microkernels. Its binaries are rather large, compared to other projects with similar features. Many users find the modularity worth it, though.)