Check out the link that he is responding to in his essay (why should I ever use C again). There's an entertaining argument about speed in there - (I'm paraphrasing here)... If speed is so important, why aren't you writing assembly? The mostly likely answer is that slower C is better than fast assembly. But then why isn't slower <your fave> better than fast C?

The logic isn't 100% airtight - it is possible to argue that benefits of C are sufficient to take the performance hit over assembly, but not so great to take the hit from C to Ruby.

That's a bit of a red herring. Everybody "knows" C is fast, but much of the time, it's no more than twice as fast as some higher level languages (Lisp, ML, Haskell, Java). I'm also willing to bet that applications where fast matters so much that half the speed is unacceptable are much less common that applications where small matters so much that twice the size is unacceptable.

Main reason I didn't mention that is because speed is rarely the main problem in my field (embedded systems). People have used bytecode interpreted Forths (usually a 10x slowdown) on slow micros and it's often good enough. In fact, a C-to-bytecode compiler might be a good idea for size reasons ... but there probably are some out there already.