Hi Erkut -
 
Great topic, though I think you'll probably find that opinions will vary pretty widely.  The only objective comment (really a question) that I can make is that it depends on the deployment model.
 
My opinion is that if you're deploying CVP in Comprehensive mode with ICM/UCCE, then multiple smaller apps are better.  A couple factors leading to this opinion, which partially address some of the cons you listed:
 
1.  Generally with this deployment model, your primary reporting source is ICM/UCCE (WebView now, CUIS future), so data transfer is inherent with the use of ICM as the "brains" of the call flow.  This assumes basically prompt/collect type apps.  Not that they can't be complex, but basically apps that you wouldn't necessarily need reporting from a CVP Reporting Server for (things like a speech app where data would be relevant to tuning, etc.)  However, as CUIS becomes more prevalent, the integration of this data becomes less of an issue.
 
2. If the apps can remain "generic", as you suggest, then the overall number should be able to be kept low.  Again, integration with ICM allows a single application to perform seemingly "custom" functions.  For instance, a simple app that collects a single digit can be the "menu" application for any number of groups or menus.  You can use data passed by ICM to play the specific prompt, and you can use ICM to handle the information returned to provide the discrete treatment.
 
Like I said, you'll probably have varying opinions on this, but it has become my preference these days to even break up applications that are necessarily "large" into multiple pieces whenever possible.  With the pages and Application Transfer element, this becomes easier to do in CVP Studio, and I think the benefit of easier support and administration is worth the extra number of apps and any additional work during initial coding.
 
 - Bill

The deployment model does make it difficult to have multiple developers working on a single application, even if they're only working on separate internal flows.  Application Transfer is probably your friend in this case though you may pay for it in reporting.
 
We have been running multiple applications since moving to the CVP environment from our previous IVR solution.  The last time we upgraded Application Transfer became available.  Since multiple application invocations within a call were broken (CS v3.6.10) I attempted to use Application Transfer as the solution where our menuing application transferred into an identify & verify application.  The issue I ran into was that the ICM routing scripts were dependant on the intermediate values from the menuing application so when the patch fixed the bug in CS, we moved removed the Application Transfer from the mix.  As long as your building the entire application from scratch then you can avoid the intermediate data pitfall.
 
Reporting is a different problem.  Since I do have the multiple-application call flows, I run into the issue of 'overstated call counts'.  If a call routes through the menu and the ID&V applications then simple counting sees it twice.  However, if you use the ICM call key as your call identity then you can roll-up the 'segments' of the call (individual application fragments) into a single call.
 
Given all that, I think you'll find the separate application path easier to build and maintain making a little pain in reporting worth it.