Because developing sites that work only in Chrome is similar to how sites used to be tailored to IE users. If we're all about interoperability and openness, having something that only works for one subset of users isn't all that open.
http://www.pcmag.com/article2/0,2817,2397158,00.asp is a year old, but its message is still true: "Sure, anyone can make a site that works in Chrome, so it is open in that sense. But if that site only works in Chrome and not in other major browsers, we have a lack of openness in the Web ecosystem."
Chrome isn't at fault for this, though. It's a combination of people wanted to test out and play with the new stuff (a good thing), and not being thorough enough to add all the extra vendor prefixes where possible (which is a waste of time on some things if it won't work anyway).
I wrote a library to abstract the code needed to access the user's webcam through the browser. I had to hold off an experimental launch for around 3 months before I could say it was widely supported, and not just by Chrome.
For experimental stuff, I don't think it's reasonable to hold back like that. It's a great way to check the robustness of an implementation, or the viability of an idea, before it becomes mainstream.
Sorry, but the situation is not even remotely comparable. Nowadays when a new CSS feature is introduced by a browser vendor (using a vendor prefix), it is designed to be standardised and implementable by anyone. Other vendors may contribute and there is discussion. If the feature gains popularity, it will eventually be implemented by big players and become a [first de facto, later de jury] standard.
The posted link is an example of experiment for measuring whether the new fancy stuff is good enough.
In the dark days of IE era, MS mainly exposed its internal Windows APIs (and security holes) to its browser. (Yeah, there was some truly good stuff too but that doesn't make MS less evil.)
Yeahhhh, calling Chrome the new Internet Explorer is missing the forest for the trees. Recall Internet Explorer made it so that you would write regular markup and THEN have to write special markup and add extra rules for compatibility.
It's the other way around here. All regular markup renders fine on Chrome. However, they are working on future implementations of the standard, so many things you want to use might only work on Chrome or webkit browsers.
Also, Firefox has prefixes that only work on Firefox. You wouldn't call Firefox the new Internet Explorer, would you? Hopefully not, because that would be like calling Chrome the new Internet Explorer.