Probably worth clarifying whether you actually mean the Second Edition of Kernighan and Ritchie's book "The C Programming Language" which is about ANSI C and thus approximately ISO C89, or you literally meant what is called "K&R C" the language described in the 1978 edition, by the same name, which is a language somehow composed entirely of sharp edges.
I started reading through/doing the exercises earlier this year and I noticed there was a lot of "cute" tricks in their code examples, such as loops that perform functionality that's all defined in the control flow definition (init/condition/increment) of a for loop, and instead of a loop body it's immediately followed by a semicolon.
Perhaps they're just to give you a better understanding of the more minor details/intricacies of the language, but I couldn't help but think with a lot of their code, if I saw a coworker write something like that I'd roll my eyes that they didn't do it in a more obvious way.
I think that the way K&R writes C is probably idiomatic C just de facto. But it's also reasonable to believe this style is completely unacceptable for maintainable code today and should fail review for example.
So, it's not crazy to argue that because idiomatic C isn't acceptable therefore rule out C as a language for an organisation to use entirely. Clearly if you don't have an alternative this highlights a problem rather than itself being a solution. But it might be a reason not to do whatever it was you were thinking of doing at all. Do you really need to write micro-controller firmware for your project? Isn't there an off-the-shelf component where it's not your problem to maintain the horrible C code that makes it work?
[ Or you could go all Oxide Computer Company and decide no, C is just terrible so we are going to use Rust and if we need to rewrite the firmware on this switch that's what we'll do. That might make total sense, if you go into it clear eyed ]
