I often see this kind of advice and it always reeks of "I went through this and I turned out ok, so you should do it too."
The problem is that I think it's completely the wrong thing to do. One of the major effects of programming in a language extensively is that you start to "think" in that language whenever you have a new problem. This is both good and bad, of course, because while it helps you become proficient in the language, it also prevents you from seeing possibly simpler solutions (i.e., that aren't easier in your language).
Also, languages don't arise in a vacuum -- they're designed in a certain time period, with various assumptions about environment and hardware baked right in. This can be extremely dangerous because as a user of the language, you will start to think in terms of those limitations as well, even if they no longer apply! So for example, C is one of these languages I'd strongly NOT recommend, unless you're working in a domain where it's necessary/preferred (low-level networking, some embedded devices, etc). C assumes you live in a time when computers are quite slow and have little memory (both of which must be very carefully monitored), there's only 1 processing core (so you can just do sequential programming), and programmer time is less valuable than execution time (so you can spend days optimizing the hell out of small routines). But the times have changed -- computers are fast, they all have multiple processors, there's a lot of RAM, etc. Most people want to be building more complex things, and for 95% of applications, I'd wager that C is exactly the wrong language to be "thinking" in.
Starting with a more "modern" language (which includes the LISPs, despite them being older) lets you avoid these preconceptions.
Also, there seems to be a lot of penance involved in the parent's advice -- "you need to pay your dues first and get your hands dirty." Fuck that shit.
Sure, if your end goal to is to really learn this low-level stuff, then go for it. But if your interests lie elsewhere, do that instead by jumping right into that domain. Maybe you want to build large distributed systems, or come up with new visualization tools, or build a logic system. C seems like a remarkably bad choice for these and so many other projects. In fact, it seems like a bad choice to even learn C first, precisely because your notions of what's possible, of the "right" way of approaching problems will become infected with the C mindset.
Most importantly, motivation is a key resource you must not squander. For many people, fixing broken computers, struggling with a difficult operating system, or looking at assembly and network packets is grueling work with no payoff. I'd be willing to bet that for such people (many of whom could be great hackers in other domains), the parent's advice is sure to sap your morale and turn you off from programming.
Finally, time is not an infinite resource either. Why waste your life on things that don't interest you and won't help you much in the long-term? Work on things that excite you, and you'll not only be so much happier, but you'll also learn much more in the long run.
P.S. I know several "real hackers"/"good programmers" and while some of them might fit the parent's description of such, many of them also fit the parent's description of the poseurs -- the A-student in my class back in college, the guy recording lectures in polo shirts and khakis, the family man with a wife and kids and a mortgage. Stereotyping is still stereotyping when applied in the opposite direction.