Because a general purpose device (in this case, the browser) generally falls behind in a few ways compared to a specific purpose device (in this case Skype). A few examples:
Stability: For Skype to break, you need to either crash Skype or the entire computer or O/S. For your in-browser conferencing, you just need the web browser to crash.
Connectivity: Skype has put huge amounts of work into punching through firewalls, and has many settings dedicated to that. Furthermore it's a common enough option on SOHO/consumer routers to let it through. P2P browser connectivity just isn't there yet.
Security: Our firewall at work is configured to allow Skype through. I doubt it's configured to let browsers open direct raw socket connections to any IP and port they please. I can't even begin to imagine how a network administrator is supposed to lock these capabilities down, other than completely disallowing them.
UX: Again, Skype is a dedicated program so it can do a lot more. It can keep a little overlay window open in the corner of your screen so you can look at a web page or document but keep an eye on your call. It can hook into the O/S to ensure your microphone is selected and unmuted. It can tell your music player to pause when a call comes in. None of this is possible with a browser (yes, you could add APIs, but where do you stop - are browsers going to become the next JVM, creating a cross-platform API that plasters over the differences between O/S's?)
My last point is mildly tangential: Why would P2P in-browser conferencing disrupt Skype / Polycom when it has literally zero perceivable difference to the end-user compared to regular client-server in-browser conferencing (other than the fact that with P2P you will be able to connect to fewer people than in the client-server model)?
Stability: For Skype to break, you need to either crash Skype or the entire computer or O/S. For your in-browser conferencing, you just need the web browser to crash.
Connectivity: Skype has put huge amounts of work into punching through firewalls, and has many settings dedicated to that. Furthermore it's a common enough option on SOHO/consumer routers to let it through. P2P browser connectivity just isn't there yet.
Security: Our firewall at work is configured to allow Skype through. I doubt it's configured to let browsers open direct raw socket connections to any IP and port they please. I can't even begin to imagine how a network administrator is supposed to lock these capabilities down, other than completely disallowing them.
UX: Again, Skype is a dedicated program so it can do a lot more. It can keep a little overlay window open in the corner of your screen so you can look at a web page or document but keep an eye on your call. It can hook into the O/S to ensure your microphone is selected and unmuted. It can tell your music player to pause when a call comes in. None of this is possible with a browser (yes, you could add APIs, but where do you stop - are browsers going to become the next JVM, creating a cross-platform API that plasters over the differences between O/S's?)
My last point is mildly tangential: Why would P2P in-browser conferencing disrupt Skype / Polycom when it has literally zero perceivable difference to the end-user compared to regular client-server in-browser conferencing (other than the fact that with P2P you will be able to connect to fewer people than in the client-server model)?