Andrew, Brad Carter, an Exchange Server technology architect for Microsoft, was able to provide an answer to your question (below). Note he added a couple links to MS Exchange team blog posts. Let me know if I can be of further help!

--Anne

Let’s not forget the Hub Transport role, which wasn’t mentioned in the question.  The customer must have HT, CAS, and MBX roles in each AD site where they intend to have mailboxes. And they must have at least 2 CAS and 2 HT servers/roles if they are going to have any redundancy (recommended) in the site. 
 
So an implied question here is whether it is recommended to have multiple-role servers, or whether role isolation is preferred.  Role isolation is not new to Exchange 2007.  Role isolation has been a reality since we’ve called it “Exchange Server”, depending on how you define role isolation.  With legacy Exchange we had to go through the hardening/security steps, disabling services, etc. when we decided that a given server would be a bridgehead, or front-end server. In Exchange 2003 we were able to tick a box that actually designated the server as “Front End”.  With Exchange 2007 we’ve effectively included role isolation as part of the initial Setup process to enhance security and to make deploying Exchange easier.  From an Exchange 2007 admin perspective, roles are seen as separate servers whether or not they are on the same physical box. 
 
In the past we’ve seen improved scalability when we had dedicated Mailbox servers and dedicated Front End servers.  Nothing has changed in Exchange 2007. 
 
I don’t know of any pros to having CAS and MBX on the same physical servers.  I suppose if the environment were small enough then the pro would be reduced hardware costs, but the tradeoffs would be scalability/capacity and possibly load balancing (I’ll explain this later in the e-mail). 
 
Details regarding initial hardware recommendations for dedicated roles, and mixed role servers can be found at:
Exchange 2007 Processor and Memory Recommendations. 
 
So in my experience, there are 3 typical “role based” deployments. 
1)      There are very small deployments (single server or branch-office scenarios) where all roles are installed on a single physical server (CAS, HT, MBX, and UM). 
2)      The second scenario is where the customer might have 4-10 servers and elect to have limited combined-role servers.  And as a tradeoff to be able to maintain redundant HT and CAS roles in the environment (with limited hardware budget) have elected to install Hub Transport and Client Access Server roles on the same physical servers.  By redundancy I am referring to a minimum of 2 CAS or 2 HT.  But these customers also maintain the Mailbox role as an isolated role to maximize scalability.  (i.e. 2 physical servers: HT and CAS roles, and 4 servers: mailbox role only). 
3)      The third scenario is what most enterprise customers are doing, which is to have dedicated roles, maximizing scalability.
 
Load Balancing Considerations:
Operational Flexibility: It is nice to be able to have the operational flexibility to drain, remove or add a CAS from a LB group or ISA web farm.  Once a server is removed from a LB farm, you would be able to patch it, reboot it, and add it again to the far with little or no impact to end-users.  Some of that flexibility is gone in a combined-role server. 
 
Load Balancing CAS functionality: If you have CAS installed on the same physical servers as the MBX role, the mailboxes on that server will always default to using the local CAS.  This will prevent true load balancing across the various CAS. 
 
OWA Implications:
If they use OWA, they will want to look at the difference in behavior when co-locating MBX and CAS roles on the same physical server.  This will have a potential impact during a migration:
Outlook Web Access and Exchange 2007, 2003 and 2000 coexistence
 
Clustering Consideration:
The only role that can be clustered is the Mailbox server role