You could probably set up a blog and a storefront easily within a day, and then hand that off to a non-technical client with a very limited budget. Outside of that use case, you're better off using something else, for several reasons:
Configuration is entirely stored in the database, which means setting up multiple environments for testing changes is effectively impossible. You also have no real way to use source control to track changes in your configuration.
The Drupal database schema is surprisingly hard to extract data out of, which means transitioning to another CMS, or to a custom-written app, is also very difficult.
Bugs are nasty, many, and often undocumented. In our case, we got bitten by a nasty bug regarding null fields when exporting XML -- it simply kept the last non-null value. Which was pretty problematic when that altered the nature of purchased items for thousands of customers (that was fun to fix). This also makes transitioning data very difficult.
Drupal module behavior is highly non-deterministic; you can add hooks in to, say, modify SQL queries before they get to the database, with no logging or other indication that this is happening. Debugging interactions between modules is very unpleasant.
There is no backwards compatibility between releases, which makes upgrading incredibly painful, especially if you depend on custom modules.