While I certainly agree that understanding the "how" will give you a better appreciation of the "what" and a more thorough understanding of the "why" behind man

While I certainly agree that understanding the "how" will give you a better appreciation of the "what" and a more thorough understanding of the "why" behind many languages (I was one of the obnoxiously vocal detractors when American universities overwhelmingly moved from C/C++ to Java), I think this goes a little far: When you internalize these lessons, your approach to programming will completely change. You can know which parts of a language are heavier without knowing how they're implemented. Granted, this is certainly not the same, but in a practical sense it is certainly close. Your approach to programming will only "completely change" if you've been doing things with absolutely no understanding of the performance impact of the choices you make. There are certainly people in that situation, but anyone who has had to do any profiling to find bottlenecks in code (which I would guess means most people who have been involved in professional development for more than a year or two) likely has at least an idea of which data and control structures are going to cause issues in languages they've used at length. So yes, I agree that understanding what's going on is good... but not everyone has the time or inclination to delve into the depths of C, and there are other ways to come about a useful understanding of language internals (e.g. actually reading about a language's specific features rather than simply guessing at their implementation based on the assumption that they're written using standard C idioms).