Actually, an MVC framework such as Symfony, Zend, Codeigniter, Phpulse, Cake, etc all can scale far better, and has faster development times. There is no trying to figure out how to 'code around' Drupal. Code is properly separated and follows coding standards. Sure you have libraries that work for Drupal but framework have libraries that work for EVERYTHING... not just Drupal and the code can fairly easily be switched from framework to framework. Lets see you move Drupal code to Codeigniter or Zend.
During the past 3 years I have developed several applications with the Zend framework (which I really like as MVC frameworks go). Earlier in my career my team developed its own MVC framework which turned out to operate well, but wasn't worth the immense development effort. Recently I've worked on several "sites" and one "application" based on Drupal.
What I have found in this process is that Drupal is not a content management system, but rather a framework for building a content management system. It doesn't do much out of the box with no community modules (unlike Joomla or WordPress), but its plugin system works well for developing a very wide variety of CMS platforms for many uses. Just as Drupal is not so specialized as a particular CMS, neither is it so general as an MVC framework. For example, Zend's 'router' is much more flexible than Drupal's 'menu' system and Zend's configuration system blows away anything in Drupal.
A great use case for Drupal is a "site" with lots of "articles". Adding an additional data field (say an address), theming it, and using it to filter a dynamic selection of content is about a 15 minute job that requires a few clicks in the Content-Type UI, a few clicks in the Views UI for the filter, and maybe a few template lines for theming if the field will be displayed. The user-input forms, content validation, data storage, and default theme are all handled. Contrast this to using an MVC framework where you have to add properties to your model (and update the database schema if not using an ORM), then add some lines to your edit-form view to add the fields to the HTML, then update the form-save controller action to pass off the submitted form data to the model after validating it, then update the display view to show the new field, then add a new action that filters based on your new field. This is certainly not the end of the world, but it requires a significant bit of programming.
At the end of the day it is all about using the right tool for the job. If I am going to develop an application with a custom database and data model (or based on an existing database) and just want to put a front-end on it, I'll use the Zend framework for the front end. If however, I'm going to build something that looks like a CMS with something like "content nodes", user-comments, tagging/categorization, a variety of user-roles, etc, then it is going to be much easier and more supportable to build such a system in Drupal.
With every framework there is an explicit or implicit vision baked into how it is designed. If your project fits into this vision then the framework will work smoothly and be a fabulous help over starting from scratch. If your project doesn't fit the framework's vision then you will find yourself fighting with the baked in assumptions and ultimately frustrated by all of the workarounds you have to write.