4. No, and who knows what the future brings.
As originally created, chat used only XHRs, for both directions. The websockets standard was still a mess back then, so it wasn't even an option. When that situation stabilized, we added websockets as a third way to receive chat events (next to AJAX polling and to receiving them from other browser tabs). It's completely optional, and the browser will gladly fall back to polling in a heartbeat if something is wrong with the websockets connection (and in browsers that don't support websockets, it's fine with only polling to begin with).
Switching the server -> client direction to websockets significantly reduces the number of requests. In the client -> server direction, i.e. sending messages, this reduction would have far less of an impact; there's obviously a lot more polling going on than speaking. It would however be a pretty large amount of work, probably larger than making the other direction work.
The invasiveness of the change into the chat toolchain would be much bigger in this case, since this direction of communication includes all kinds of rendering, storing, updating, etc. logic, where the opposite direction is much simpler – grab a bunch of event objects and send them to the client. Okay, I may be oversimplifying just a tiny bit.
A smaller issue that's coming to me (but I haven't fully thought this through) is that the way chat currently works requires a request-response model for sending messages (where the server acknowledges that it has received the message, what id it has assigned it, etc.). This isn't a major problem to do over websockets, but it's of course more work than just using HTTP, which is made for this model in the first place.
To sum up, I wouldn't expect this to happen anytime soon – there's very little to be gained by switching to websockets for the second direction, but a lot of work required. Who knows what'll be going on two years from now, but for now, I wouldn't hold my breath :)