"for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails" - in 2006 was true
"I’m really not sure that you won’t hit scaling problems" - Twitter's issues scaling Rails are well known
"that’s not a safe choice for at least another year or six" - For many that was true. For example, prior to Bundler (released in 2010), managing dependencies was hairy.
"you’ll be buying 5 times as many boxes as the .NET guy down the hall" - Easy to throw resources at a problem now, but pre-cloud, that required some serious capex, so it wasn't a problem you take lightly. DHH himself has acknowledged Rails needs more resources, as they aren't optimizing for that problem: "Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails." (https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...)
(FWIW, I'm 100% Team Rails these days, but I do think Spolsky's assessment at the time was valid)
Much like Facebook did with PHP at scale (Hack).
I liked Hack, never used it but it drove a huge amount of change in the PHP ecosystem, 7 was a huge step forward and so was 8 in part because of Facebook.
You can't cite Twitter as a counter-counter example, because it's definitely not a "boring" problem domain (or, wasn't, in 2006).
If you're going to give a wrong prediction like that a pass, then what the heck is the point of the scientific method?
And no, theories do not need measurable data. Qualitative results can be used to support theories (much of my hard science grad school work was basically a binary "can this happen"? That is not really a measurement in a meaningful sense unless you consider all observations measurements -- I do not).