Definitely not. Longpolling adds a huge amount of overhead when messages are sent relatively frequently. For each longpoll request, the client needs to send all the headers and cookies every time. Each response includes all headers and connection setup. A websocket connection has zero overhead after the initial http upgrade. If you have websocket available, you should always prefer websocket to long polling. In most cases where websocket would be blocked by infrastructure, long polling would be forced to retry extremely quickly because of forced timeout.
For example, long-polling can actually be RESTful, so it fits in well with conventional API practices. It's also naturally resilient to network issues since each re-poll heals the stream. Users are very unlikely to lose data due to forgetting about some corner case.
GET /orders - fetch all orders
GET /orders Upgrade: websocket - streaming view of all new orders
TCP and WebSockets are stateful, HTTP is stateless. So long polling is essentially:
Stateful -> Stateless -> Sateful
You start in a good place, then you add complexity to make it stateless and then you add even more complexity to roll back the statelessness and then you end up where you started... Except it's 90% slower and you now have to use an armada of sticky load balancers to prevent the system from falling apart...
In Go, requests are a single goroutine, dirt cheap (no problem with a single CPU). To me, this type of work is where Go excels.
I used SSE (not quite long polling but I think it has the same implications as far as this discussion goes) back in Go 1.3 days (so GOMAXPROCS=1) to write metrics to 100<n<1000 clients and the process barely registered CPU or memory usage. No lock problems either (copying metric values over channels).
As far as complexity .. well, sure, if you fuck up the design or use the wrong tool for the job you'll have problems.
A lot of the examples out there in blog posts are too simplistic. They don't handle buffering old events and most of them simply give an event to the first request and then discard it. That's not real pub-sub.
I think calling this RESTful is a bit of a stretch though, at least in any conventional sense of what that means to people.