I was going to say almost exactly the same thing. The items that he listed are certainly detrimental from a startup perspective, but for a big company I think that they are actually arguments in favor of Java. Unfortunately for Paul Graham, and his prediction, the big companies have had more say in adoption than the startups. I agree with you. In hindsight, it makes perfect sense. But, it wouldn't necessarily have been obvious at the time.
Personally, I dislike the language wars. I think that a good developer should be able to write good software with the tools available. Arguing the opposite always smacked of the "silver bullet" to me.
In the end, all languages are Turing complete, but there is still a difference. It is similar to woodwork (from the small dabbling I've done in woodworking): good tools make you faster and can produce better output. You can produce the same quality, but it takes a whole lot more effort.
But more important than the tools you choose (Makita vs DeWalt, Chevy vs Ford), getting to know them is far more important. And that's where the language wars seem to fail: the recognition that a guy with 15 years of good Java experience will code circles around that <insert your language here> beginner.
XML is not Turing complete, nor are most configuration file formats. Yet these are used to provide significant behavior. They are are programs. Programs are data. Data are programs.
> I think that a good developer should be able to write good software with the tools available.
While that's true, it would be hard for me to consider someone a good developer if they, given the choice, chose poor or inappropriate tools for a job.
Sure, if you have the choice. But that's were the Hacker News startup culture and the enterprise development culture diverge. In a small startup you can dictate the tools. In an enterprise company you may not have any say in the matter. You can either complain endlessly about it (and boy howdy are people willing to complain endlessly) or you can do your job to the best of your ability with the tools available.
I understand where you're coming from though. I just think that you need to know a lot of context about the developer in question before you dismiss him/her over their tool choices. You need to know why they used those tools and how well they learned them.
But what it really comes down to is how fast the developer can learn something new. I'm fairly confident that I understand enough about programming language concepts to be up and running with a new language in a few days. I might not know the API (if one is provided) but I will probably be able to contribute to the team pretty quickly.
Personally, I dislike the language wars. I think that a good developer should be able to write good software with the tools available. Arguing the opposite always smacked of the "silver bullet" to me.