There's nothing wrong with using HTTP if it's done in a sensible way.
In the early days of the realtime web, long-polling was used mostly as an underlying hack in the emulation of streams. However, RealCrowd's API isn't a hack. When clients make requests to the server, they are attempting to synchronize a resource. One could argue that this kind of interface is semantically closer to what the client is trying to accomplish than one based around pure message passing.
Yes there are real problems with HTTP. There is a lot of overhead in building a connection and maintaining. It's designed to be a transient, request/response oriented protocol. Things like XmlHttpResponse are a hack and misuse.
I'm not just being pedantic about it either. Just compare server performance of RPC over Websocket to RPC over HTTP at scale.
In the early days of the realtime web, long-polling was used mostly as an underlying hack in the emulation of streams. However, RealCrowd's API isn't a hack. When clients make requests to the server, they are attempting to synchronize a resource. One could argue that this kind of interface is semantically closer to what the client is trying to accomplish than one based around pure message passing.