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.
It's not about monopolistic practices, as another reply to my comment says. It's about developers using new, incompatible technologies and thinking that everyone is using a WebKit-powered browser.
At least I didn't get a "please upgrade to a modern browser" notice in Opera, like an unfortunately high number of Show HN posts have done...
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."