If your server side stack (https terminator, load balancer, caching proxy, app/web server) can't support websockets, you'll be falling back to long polling in every browser.
My argument is that since IE does not support EventSource a large portion of your userbase will have to use an alternative implementation. If this implementation polls then you get minimal gain since now the majority of your userbase is polling again.
Caniuse.com reports 75% global relative support for EventSource and just 85% for websockets.
To claim that "you can control your stack" as a solution to a protocol that has well known issues with multiple components in the path between a client and the server is somewhat naive frankly.
As for the "pull vs push" debate: event source lets you open a channel to a resource on the server and wait for it to send you data.
XHR long polling works exactly the same way - you open an asynchronous connection and wait for data, the only difference is you need to handle reconnects, and the message parsing is done in user land code rather than in c/whatever.
Long polling is definitely not about making a new xhr request every couple of seconds to check for more data.
