Disclaimer: I don't actually work on web apps, and therefore have no experience with these things.
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.
Are you saying it's difficult in general to find good C devs? Because it would seem that's the case for C++, but not for C.
But for most web apps, rendering HTML pages from script is not the bottleneck, it's the interaction with the database, and the solution is intelligent caching to reduce load on the database. The tools to mitigate these problems are already written in C (memcached, etc).
Luckily rendering scales just by adding more servers.
Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible.
Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.
It is highly unlikely that happens. Once you lower your DB issues, if the application is responsive enough you start working on other features. By the time you're done the application got new users and the DB is a problem again ... it's a cycle :)
Fortunately HTTP servers do scale by caching and load-balancing.
The author of the post probably never worked in real-world conditions. You first have to have users and real needs for scaling, and that doesn't happen unless you deliver a useful application first, and you also have to deliver it pretty fast, otherwise you might lose to a competitor with the same idea.
Not really. Sending and receiving data to/from the browser becomes the bottleneck.
If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser.
There are, unfortunately, limits on how much that can be improved.
However, most website projects are business-driven, which means that you are constantly changing and refactoring stuff as misunderstandings get cleared up, design flaws emerge, business models change, minds change, etc etc.
Business software projects are not just engineering, and if you treat them as such you will endure pain.
The analogy with a house is odd - if a house was purely an engineering problem, then they would probably all be built out of precast concrete or something, not "wood and steel". Aesthetics, tastes, budgets, and tradition all have an impact, and nearly every house is unique, so you use the "best tool for the job" - the one that is the easiest to customize on-site.
When requirements change weekly and by the projects end your original project description is only useful as a piece of history - then using concrete would mean lots of demolition work in the process.
It is done occasionally though; last I heard, large portions of Amazon.com were written in C.