This is one of those posts I started back in mid-October and sat on, suspecting that there would be more follow-up, backlash, challenges, and general bickering. There has been some, but then it died down a bit. And then I remembered I should post this.
The post goes into some detail outlining the methodology for capturing the data, which is worth reading for the follow-up posts, but here is the breakdown:
Update: February 11, 2011
Updated: October 22, 2013
Update: May 7, 2015
I can't accept your conclusion. Given that development time is infinite, I agree. But development time is very, very finite.
You choose, then, to put time into the 2% that don't have JS. I choose to put the same time into making a better site for the 98% that have JS.
I think you have it backward. Any functional public-facing site must not rely on client-side script to accomplish all its core functionality. For example, if you are doing forms validation, it must still be handled on the server or some combination of non-JS-capable browsers, users who like to "hack" forms, and spam bots will break them. I can't imagine you wouldn't trap for SQL injection attacks on the server. That's just standard development practice.
This standard and best practice also happens to support your non-JS users.
I can tell you from 15+ years of practice, this does not increase development time.
If you are putting time into building support for non-JS users, then your development process may be going in the wrong direction.