Just to be clear: It is true: If you're sending 10 packets a second with a 20 byte payload, HTTP is likely not the right protocol.
We actually do send binary-only messages over our IMQ infrastructure for some games that have that use case.
The article in question wasn't quite the right vessel to talk about that, though -- gotta stick to one general topic at a time :-)
The topic here is low-latency invalidation of REST service data (plus avoiding death-by-request-latency) when things "randomly" change.

Is IMQ using websockets in javascript for the TCP connection to the server from which it gets data pushed to the client?

Is IMQ using websockets in javascript for the TCP connection to the server from which it gets data pushed to the client?

IMQ actually supports three models:

1) protocol buffers over raw TCP -- great for mobile and desktop apps
2) protocol buffers over websockets -- great for modern browsers in non-hostile network environments
3) protocol buffers over JSON over HTTPS -- "mail drop" style polling, for that last 1.5% of users who connect from internet-hostile environments

The client libraries for different platforms will try the "best available" and fall back based on success/failure, largely transparently to the application.
The server side is largely oblivious to how the user connects entirely :-)