RE: Pagination ... considerations; speed to load data, number of trips to server and perceived slowness of the client application, types of views that need long running persistent data tables.
Without it, you risk the "it takes this thing a looong time to load!" complaint. With it, you get the "it takes too long to load the next page!" complaint. I think a happy medium is pagination with read ahead caching of the data into pages of xml controls in the client so you can swap pages back and forth with little lag for the user unless they page quickly.
Another side of it - seems to me that views that are long on document count need to be rethought. Is all that data relevant? Would a search tool serve better? How often does one need to visually scan row after row of data? I think the more we look at ease of use and accessibility of data on top of all the data we accumulate, we have to look seriously at the Facebook model - recent data first and foremost, pagination upon request. I think search technology is a better approach to finding data than sifting through a view anyway, so that would trump pagination in my mind.
BTW - your flex code is coming along nicely from the looks of it. Wish I had an active project that called for it - pretty much done with any flex work for the next few months unless a need arises where I'm working for a client... where I think the chances are slim. :-( But - looking forward to trying (yet) the accounts on LAMP!