I have seen this quite a few times myself and in most cases, depending on where I was capturing traffic, this was the result of propagation delay.
If you're capturing somewhere upstream closer to the sender, particularly in high latency links, you will see lots of packets sent to the receiver before the receiver has time to receive, process, and acknowledge the packets and for those acknowledgements to make it back over the network to your capture point resulting in an apparent "ack burst". Propagation delay is what causes this effect.
Now, this traffic pattern can also be caused by many other factors (e.g. low or over-utilized CPU/memory/etc. resources, poor NIC drivers, or old NIC hardware on the receiver), but in most cases I have dealt with this was the result of good 'ole propagation delay/high latency.
This effect is sometimes better understood via an example:
Take a scenario where you have a server and a client separated by a wide area network that has a bandwidth capacity of 100Mbps and a end-to-end network latency (propagation delay) of 20ms round-trip-time (RTT).
The client has advertised a classic TCP receive window (RWIN) value of 64KB, transport is IP, MTU and TCP maximum segment size are 1500 and 1460 bytes, respectively, and the server is sending a large file via TCP to the client.
In this scenario, congestion windows/slow start, selective acknowledgments, and RWIN scaling are ignored for simplicity's sake.
Due to the concept of receive windowing, the TCP sender (the server in this case) knows it can send up 64KB of TCP payload data before the client (receiver) acknowledges it has received any of that data.
With an MSS of 1460 bytes, this would equate to 45 packets for a total of approx. 526Kb (64KB + TCP/IP overhead / 8 bits per byte).
At 100Mbps, the server is able to send those 526Kb in approx. 5.3 milliseconds. The server is unable to send any additional data until the client starts acknowledging the data that has already been sent (data in flight).
Because of the propagation delay of the network, it takes 10ms for the first data packet to arrive at the client (20ms RTT/2 = one-way delay). Even if the client acknowledges each packet immediately as it arrives (or more likely, due to delayed acks, acknowledges every other packet), those acknowledgements will take another 10ms to travel from the client back to the server.
By the time the server receives the first acknowledgement, it will have already been waiting for at least 14.7ms since it sent its last packet to the client, with the rest of the acknowledgements arriving over the next several milliseconds.
When capturing traffic on the server side, this will appear as a burst of data packets from the server, followed by a delay, followed by a burst of acks coming in from the client, followed by (or interspersed with) another burst of data packets etc. until the data transfer is complete.
What's important to understand here, though, is that from the client side, it is acknowledging packets as soon as they arrive, and indeed if you captured on the client side, you would see a delay, followed by an even mix of data packets arriving and acks being sent out, followed by a delay, etc.
This is why it is very important to understand where the traffic capture took place when interpreting it.