So We check cdo and mapi32.dll on first time. On BES/Exchange is the same. Maybe you right about pending messages and hung threads. We restart servers couple times. For some users We use statistic Mailbox Agents and messages flow is very good 
I thing the restart server couple times make very big overload of server (scan mailbox, recount pending messages). But We have some users "failed to start" and I think this is corresponding to access to exchange mailboxes for this users.
I don't believe the fix from RIM will fix the delay issue. They are hoping the fix/buddy build they have that corrects the memory leak with the rpc client access service will resolve this. (I'm on the inside loop on this as this bug was reported first in my company's name.) In order to get this from Microsoft, RIM needs several counters to prove the memory leak.
They are aprox. 3-5 days out in getting it backported to SP1 and SP1 RU1.
However, we are experiencing the delays as well. We have been tracking this with microsoft outside of this other issue and what we've come to discover is that the notification handler on the cas servers is a queue. This queue "fills" and removes the oldest packet before it is delivered.
If you open a ticket with Microsoft on this, they can confirm by running "extra" on the CAS, configuring the notification handler and then uploading the trace to them. Unfortunately these traces from what I can see cannot be converted to a txt file without them (.etl files.)
In end, unfortunately this is a microsoft issues, not RIM at all as there is nothing RIM can do about Microsoft Exchange not delivering them the proper notifications.
One avenue I was going to look at, is since we are using outlook 2003 (mostly in cached mode but some in online mode) we made a registry change to effect the polling.
We are considering changing this back to the default and see if it helps with the flooding. Just a thought.
