A big problem for the analysis this old project attempts is that C makes no effort to clearly define any circumstances it doesn't care about and yet many such circumstances are likely to arise in real world programs. I would consider this a defect in a modern language, but of course its proponents disagree.
+1. I think the simplicity of C (and also Unix) was a great idea when it first started, it allowed so much productive explorations and works to be done in a short amount of time. Unfortunately, after decades of development, programs and systems were getting increasingly sophisticated to the point that the original design was not prepared for. Then one starts to suffer from a myriad of design limitations, and people start adding complicated extensions and workarounds to the existing platform, and eventually you get something that is not simple at all.
At this point, the simplicity became a shadow of its former self.
For example, in C, nobody could tell exactly how many undefined or unspecified behaviors exist in a program. Historically, every major optimization technique in a new compiler releases would uncover some unintentional undefined behaviors and would break existing programs. Recently, to solve this problem, UndefinedBehaviorSanitizer has been developed, which is technically a super complex tool. In the same way, the memory safety problem led to the creation of stack canary, NX, ASLR, PIE, CFI, AddressSanitizer, large-scale automated fuzz testing, none of them is simple. Arguably, all of these complexities can be removed if the programming environment itself has a better memory model.
For another example, C stdlib's minimalism caused many attempts to create a powerful standard library. While C++'s STL and Boost are notorious for their all-encompassing features, but arguably the recreation of a homegrown library in all C projects have made them more complex. Not to mention the C stdlib's minimalism is also a shadow of its former self - people claim one could essentially internalize all the functions, well this could be true for ANSI C, but how many people know that C99 has native support for complex numbers? Or how C11 added multithreading?
The Unix situation is similar. When it got popular enough, people started to add more and more features and extensions to satisfy their needs. Nowadays everyone is saying that X is bloat, but if you're a retrocomputing fan and look into the history, you'll see that this has already been the trend ever since the popularization of Unix. It has already began during the early BSD development at Berkeley - students added tons of command line utilities and optional arguments which was heavily criticized by Rob Pike. During the Unix Wars, various vendors also packed lots of features often in a hurry and in a manner that lacked consistency, which was subsequently adopted by everyone because POSIX was the peace agreement. When 4.3BSD started supporting POSIX, ironically, this time it came under attack by some as moving away from the BSD philosophy of simplicity! Later, GNU also added tons of features to the system utilities, sometimes explicitly went against Unix's design to address its perceived limitations (GNU's Not Unix, after all). Eventually there are Linux kernel and systemd, which clearly do more than what a kernel or a service manager is supposed to do. Linux kernel even has Transport Layer Security now!
Most of the feature expansions in C or Unix really have useful purposes and solves real problems in spite of the claims of "bloat". The problem is you have an aging foundation with a false pretense of simplicity, and when extensions are added to meet the demands, they create a lot more complexities in real applications, and the "simple" system with extensions is actually more complex than a "complex" system with a more elaborate design.
Don't get me wrong. I still find the C Programming Language is an excellent work of technical writing, its concise and minimalist style has its own elegance. Also, I still like The Unix Programming Environment as described by Rob Pike, it's revealing how much useful work can be done flexibly in pipes and shell scripts. However, I have to say that the computing needs have progressed far beyond those days - I know how Worse is Better works, I also genuinely believe that the adaption of Unix as a base platform and the "exploitation" of its viral nature by the free software community is one of the most important successes in history - But all I want to say is that, Worse is Better does have its costs.
Probably the best non-fiction book I own, Ambrose Bierce and Randall Munroe's books are funnier, my X references are more useful as monitor stands, and my sister's book about cloth (she's an embroiderer) is much prettier, but K&R is the best book.
Perhaps it's notable that my "Student's Introduction to English Grammar" by Huddleston and Pullum is of similar size to K&R. Of course, Huddleston and Pullum merely happened upon English's Grammar already fully formed, which they can only try to explain in retrospect, whereas Ritchie wrote the first C compiler.