First, MODx is not Drupal, nor is it WordPress or Joomla! It is architected in a different way, for specific reasons. It works in a different way. I can create a MODx web site with 1 Resource that serves 1 million blog posts efficiently. It’s just a matter of choosing the right solution to the challenge at hand. Creating a Resource for each one of those 1 million blog posts would never be the right solution in MODx though. It might work in WordPress because WordPress is designed to handle large volumes of specific kinds of web content, namely blog posts; not just any kind of web content.
Second, MODx 2.0 (aka Revo) can already theoretically handle unlimited Resources. And we will of course be improving the system based on real world usage as development and releases continue. But you can simply turn off the caching of context settings (cache_context_settings). You will lose baseline performance on any requests that use non-cacheable Elements, but you will gain the ability to handle a larger volume of Resources limited only by your physical server limits; no monolithic cache file of all the Resources in the Context. But there is always a complex tradeoff between volume and efficiency, and I like to be prepared for unexpected volume from the beginning. In that sense, I don’t think this really is about "Enterprise App Development" as much as it is simply about designing for scalability and reusability, of both your presentation logic and your raw content (or data).
Regardless, I will never see data as web content. Data is raw content that is representing something specific. Whether that be in a RDBMS, or accessible from a web service, or in a schema-less NoSQL database makes no difference. Web content is a specific "view" of that data; formatted in some way for delivery on the web. If you have two different ways you want to present 30,000 items, are you going to create and manage 60,000 Resources or are you going to build two views into 30,000 pieces of data? And besides, IMO, you simply do not manage data in the same way you do web content. Consider a blog with the ease of use of WordPress. The bloggers don’t want to see a tree of the entire website necessarily; if you can now create a unique and custom UI for managing and writing blog entries and deploy that over and over again inside any MODx site, which still provides the cool site tree for the rest of the web site that is not so bloggy, wouldn’t that be ideal? That is what we are talking about. Do you want your web catalog inventory managed in the same way as your marketing web pages? And do you want that product data to be handled in the same way as your web pages? MODx Resources are treated in specific ways to optimize them for delivering web content, not for being collected and summarized in 10 different formats across the web site, made available as web services, etc. etc.
Anyway, I’ll stop, but the intention of MODx Revolution is to provide a framework to build a powerful toolkit of reusable components for constructing and organizing anything that is going to be presented on the web. It is one part PHP framework and one part web CMS. I think as you see new features and Extras become available for this truly unique product, you will start to understand that we all have the same goal in mind here: an easily extensible and customizable web platform that provides creative freedom without sacrificing power and scalability. And as more MODx developers create solutions for specific web problems, you’ll be able to let MODx handle your yearning for the infinite without having to code a CMS within the CMS.