Long polling is always beneficial since it results in higher performance at reduced cost for the majority of use cases. Unfortunately, you cannot control the number of messages each worker receives from the queue due to the distributed nature of the queue. But there are some client-side workarounds that can help you in balancing the load for workers.
So, this is what we did as a workaround for this:
As one of the workaround, the poller script can control the number of messages each worker receives. A threshold can be set for maximum number of messages each worker can handle. This threshold can be a dynamic value and would probably be
ApproximateNumberOfMessagesVisible divided by number of pollers/poller scripts. You can then keep the visibility timeout to be any lower value so if all the poller scripts are long polling at the same time, one of the pollers grabs the message, decides it is overloaded based on threshold, does not delete the message, the message goes back to the queue and it could be grabbed by other pollers who still has the capacity to grab the message. The threshold parameter can be fine tuned to meet the application's needs.
Also, having failover mechanism would help too, like how the answers in this post describe. However, I can't afford to have failover queues in a distributed architecture, as it would increase the complexity. So, the above workaround was a better idea for my team.