I've submitted a bug report to Apple - not sure if they will regard this as a bug, but I certainly do... I await a response - but I'm not optimistic.
I did some tests on OS X El Captian vs OS X 10.8 and in a more general test case I found that just doing anything which took longer than about 15ms to complete (even a usleep(some tme) ) in the mouseDragged callback of my plug-in NSView - without any UI redraws, caused an NSTimer on the main RunLoop registered with NSRunLoopCommonModes to stop firing while the mouse was moving. In contrast on 10.8, you can increase the usleep interval to relatively much longer intervals, and while the timer fires at a progressively slower rate, as to be expected as the RunLoop spends more and more time in the mouseDragged callback, it doesn't seem to freeze up. It continues to be called.
So it would appear that whatever changed, it means that if mouse input events queue up faster than they can be handled, the RunLoop becomes bound up processing them and now, never checks / services expired timers (or other processing further down the loop).
It could be a deliberate design change, but I hope not (though, it could be hypothesised that this kind of agressive focus on processing user input to the exclusion of any other background tasks makes more sense on e.g. an iPhone than it does on the desktop, with all that that implies...)
(I've also noticed similar issues in ProTools with freezing meters etc, and affecting some of Avid's plug-ins in a similar way)