Because
most scaling problems in web apps are ultimately architectural. Yes, you may need to buy a second server sooner rather than later if you run Ruby instead of finely tuned C or C++, but for most apps you're going to need to worry about a second database server and replication before that, and long before reaching either you will have enough traffic that you'll need to prepare to handle front-end scaling properly soon anyway.
An example - from messaging middleware, not web frontends since it's somewhere I do have proper data:
I did a messaging middleware system in C a couple of years back. It's easy. I've done it before. After a while needs were changing and I decided to try writing the replacement in Ruby. It was a lot quicker to write (1/10th of the code size for roughly the same feature set).
We were handling 3-4 million events a day, which could easily result in 2-10 messages each.
The Ruby replacement spent 10% of a single 2Ghz Xeon core handling those messages. Of that 90% was spent in the kernel handling system calls that would've been roughly the same in a C/C++ version.
Even if the Ruby part of the equation was 10 times slower for the userland part, the most we'd have saved for our load was 0.9% of a single core. The most we'd save overall, regardless of scale, would be around 9-10%.
Doesn't mean there aren't things for which a language like C is better suited - I did my MSc. thesis on reducing error rates for OCR, and some of the image processing I did was prototyped in Ruby, but then translated to C for the final version because processing literally would've taken days for things that took less than an hour in C.
But scaling is very often constrained by other things than the performance of the laguage you write your app in. Especially in the web space where most interesting apps are database backed.
If your DB gets maxed out, having a hyper-optimizing compiler is not going to help you. If your app isn't designed to be scale across multiple servers (or at least cores - these days you can rent managed hosting on a 24 core server for less than $1k/month) you could very likely be screwed in ways that no compiler will save you from.
The extra developer time spent doing web development in low level languages is unlikely to be worth it unless you're at a massive scale.
If you can fit in 24 cores with a language like Ruby, your best case saving from switching to a compiled language these days is around $10k/year on hosting if you're ok with a single server, and about $20k if you want redundancy.
That doesn't pay for a lot of wasted developer time. Most web apps can fit in that, and for the lucky (or unlucky, depending on reason) that need to scale beyond that, the CPU time spend on the actual web app is likely to be a relatively small fraction of the total CPU time spent (on databases etc.) - architectural decisions is likely to be a far more important cost driver than the language of the web frontend.
As for developer availability - good luck to him finding good C programmers, and even more so finding good C programmers who aren't expensive and knows web development.