This limit refers to the number of events waiting for dispatching, not to the event size. The limit is applied for each single item, or more precisely, to each single subscription.
In normal cases, the Server should not need to use these buffers, as it should be able to send all events in real time.
If you subscribe to an item in a mode that allows filtering, then your subscription settings should also request a small buffer size (note that, for MERGE mode, a buffer size of 1 is requested by default). On the other hand, if you subscribe to an item in a mode that doesn't allow filtering, then you should ensure that the event rate for the item is not higher than the expected dispatch rate.
The buffer is there in order to allow bursts of events to be dequeued, but, if the event rate for an item is steadily higher than the dispatch rate, then the buffer usage grows and this impacts both on dispatching delays and on Server heap memory usage. Note that some factors may reduce the dispatch rate even for items subscribed to in an unfiltered mode: these are bandwidth limits, network or client slowness and Server-edition-specific frequency restrictions.
See also "itemEventBuffer" in
General Concepts.pdf.
