WebSocket consists of a simple Javascript API and a protocol definition. It is fairly simple in concept and the Javascript API makes it very easy to use within any web page.
There is lots of talk about compatibility, support and issues with WebSocket which is why most people probably won’t use it directly, but instead use one of the many products or open source projects that wrap up WebSocket and provide some fallback mechanisms for the environments where WebSocket will not work. Since there is an API on the client side it is easy to make these wrapper APIs conform, therefore it is easy to swap it out for other products or remove completely if there is ever a time where WebSocket is ubiquitous.
The problem is, on the server side, there is no API, just a protocol specification.
Existing server side APIs
Years ago there was CGI, a defined interface for writing dynamic content from a web server, this was used by shell scripts, perl scripts, compiled binaries, and these things were fairly portable – at least the portability was in your hands, for example, if you used perl you had to make sure you had perl in your environment. Next came more advanced APIs, Java Servlets, Microsoft’s ISAPI. Servlets, more so than ISAPI maybe, meant you could write Java based server side web applications that could run on any web server or application server that implements the Servlet API.
WebSocket on the server
As simple as WebSocket is to use on the client side, the lack of support for it and therefore the necessary fallback mechanisms prevent it from being usable on it’s own. This leads it to only really being useful within specialist products such as Comet servers which have their own APIs on client and server (Some may expose a WebSocket like API on the client). In these scenarios you haven’t really opened up any new possibilities, Comet servers have been doing this without WebSocket for years, WebSocket just brings a new transport mechanism which in some areas is better, but ultimately the user won’t notice.
Writing a WebSocket application ties you to a particular server side implementation of WebSocket. There is no API to write to other than proprietary ones, and since the whole paradigm of WebSocket (bidirectional communication) does not fit in with traditional web request/response based APIs, such as Servlets, you cannot really write a WebSocket application using existing server APIs. From early discussions on the WebSocket mailing list, it was clear the authors had the goal to make implementing WebSocket so simple that this would not be an issue, as you could just simply implement WebSocket each time you wrote a WebSocket application. To me this seems a bit naive – people have to fit in with existing infrastructure and since WebSocket is not ubiquitous you need fallback mechanisms which are not trivial to implement from scratch each time.