In college I'd programmed Fortran on punched cards. APL was like dropping acid, and I worked one summer as a commercial APL programmer, but it wasn't appropriate for what I needed. Pascal didn't quite fit either. C was in that context mind-blowing. The future had arrived! I had full access to the machine!
If one is learning to become a plumber, one might not be so interested in how plumbing worked in 1840. If however, one is a herding dog, and needs serious work to avoid getting bored and destructive, reading K&R would put C in historical context.
Later, as I depended on C, I bought each edition of C: A Reference Manual by Harbison and Steele, and read it as if I were studying to be a lawyer.
I now program in Haskell, and wish I was equally versed in Clojure and Rust. If I were returning to C, I'd instead choose Rust. For my work, I have a free choice.
This made me laugh. I always described it as feeling like a collector/completist, but lawyer works too.
Visitors to my home office (back in the dark ages) would often comment on the growing set of editions of "UNIX System Administration Handbook", lined up side by side on my shelf.
Honestly at some point in editions 3 through 6, I was just buying the new ones for the shelf art.
RIP Evi Nemeth.
C has few concepts. You can learn to write C in an hour with a couple of web pages. Then you have to learn how to implement the most useful data structures but that’s not difficult either. What’s hard is writing safe code in a maintainable way and K&R does very little to teach you that properly.
There are probably some sharp corners I’m not thinking of around type conversions but that’s the kind of thing you expect from a strongly typed language.
Most of the caveats are in how compilers treat C rather than how close it is to the hardware to be honest.
I've read a lot of books about programming over the many decades I've been doing this, and the K&R book still stands out as one of the best examples of how to do a good job of documenting the tool you've just built. The K&R book gave me the heuristic of "read the book by the folks who wrote the language". That heuristic turned out to be mostly wrong. But the book has stood the test of time.
To appreciate C properly, I think at some point you need to become a bit of a historian. Look at BCPL. Look at what assembly listings looked like or old Fortran. Read some of the very early papers from C and UNIX history. Check out Lions' commentary on UNIX. When you see a little of the problem C was invented to solve, it becomes a lot easier to understand why it is what it is. There's a lot of angst about why C allows Bad-Thing-X or doesn't have New-Fancy-Thing-Y. Nobody seems to remember what a change it brought to writing systems code.
Then you can compare it to things written in modern C (C99+) and see that yes it has evolved quite nicely and can, if used correctly, be a nice application language too.