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.
Because C is (mostly) portable, and assembler is not? Lately it became difficult to match C even using hand written assembly. Intel's C compiler will generate auto-vectorized auto-parallelized code (not as good as carefully written assembly, but much better than assembly a novice would write).
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.
I'm surprised he doesn't mention this. I get magnitudes of speed (10000%) improvement over other languages after porting them to C.