Mike, you also over simplify things with the assumption that the entire database needs to be cached in memory to gain performance improvements. This is untrue, only the data that is actually "interesting" needs to be cached. While the size of the database is a good rule of thumb for guessing how much information there is to cache, white space and information that is "uninteresting" often compose a rather significant portion of the data. Thus, the end goal is really to avoid going to disk as much as possible for the "heavy lifting" needs of the consumer of AD.
For reference, "interesting" and "uninteresting" are highly subjective terms directly related to the client usage profile. For example, an AD domain controller servicing only Exchange servers is probably not going to gain much performance benefit from being able to cache all the computers objects in the forest in memory.
Also, you talk about "demanding" applications as having large volumes of LDAP requests, ANR searches, etc. What constitutes large versus small? What about a multitude of non-demanding applications? Does the load in aggregate eventually become essentially equivalent to one demanding application? This also needs to be taken into consideration if you are no longer isolating Exchange from the rest of the infrastructure. Eric Fleischman's recommendation of reviewing the AD x64 white paper, will provide the numbers that represent what constitutes "large" relative to load on a specific DC.