I wouldn't characterize it so much as a feature (I know that's the article's wording, not yours), but some features meant to deal with a potentially problematic situation called "mouse-ahead".
I found the explanation in "Why X is Not Our Ideal Window System" ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.2... ) to be pretty thorough. Essentially, X defines an asynchronous protocol between client and server, since they may be running on different computers with hundreds of milliseconds of round-trip latency between them.
In most asynchronous systems like this there are race conditions that must be attended to. Mouse-ahead is one such problem. Imagine that you have it mapped into your muscle memory that you need to click a button to expose a menu, drop down about 40px, then release the mouse button to open a new file. In reality that sequence of events involves a few roundtrips between you and the X client (remember, this could be up to a second). What happens if your "I released the mouse button" signal is processed by the X client before it knows "a mouse release in this part of the screen denotes that he wants to open a file"? If you don't think about mouse-ahead beforehand, the answer is either your mouse release will be interpreted as happening as whatever is under the menu, or the mouse release will be lost forever; neither is good.
So pg. 6 of the linked article suggests a solution, a synchronous grab, in which you don't actually send the mouse release command until you know the client is ready for it. I'd suggest reading the first few pages of the article, it's one of the more cogent descriptions of a real race condition I've encountered.
