Drupal is NOT a CMS.
Contrary to what you may call it, and even what they say it is - a "Content Management Platform" - I consider it to be an extensible core framework that "happens to ship with many content related features by default."
Stripping it down to bare bones would reveal a flexible and fairly well designed framework that can be used for anything really.
That's my major beef with Drupal - that it ships with so much content-specific functionality in place. For instance a node is something everyone universally agrees is a "great concept" - a basic item that is extended by custom options (CCK is the model of how easy this is) - but nodes still have a "Title" and a "Body" and publishing options and other fields that shouldn't be there in a truly generic system. The idea of one central basic element though is spot-on in my mind. With all that in mind, I begin my thoughts...
When it comes down to it, almost everything can be considered some form of a "content" item. For example, I designed something to track transactions. At first I cheated and used CCK and just made some custom fields. I also made a version using Drupal's schema API that just made a normal database table, to skip any CCK overhead and node "addons" Drupal glues on by default. However, the overhead aside, I was able to use this system and with not a lot of code, make a fully functional transaction tracking system based off of node concepts. I used CCK as a "schema designing" frontend, and could use Views to get the information back out in a variety of ways.
Is a transaction "content" in the common sense of the word? Not at all. It's a reference to someone purchasing something, in this case a user purchased another type of node - so really it was just a user reference and a node reference. I didn't care about the "Publishing options" or any of the other Drupal-related built-in node specifics, and anything else that may attach itself to nodes - Pathauto, Fivestar, etc.
I [ab]used the node-based system and CCK's UI to make myself a flexible schema to track transactions. I was also able to use pure API to create a database table and manually track the information, and skip any of the hooks related to node processing (Pathauto, Fivestar, publishing options, etc.) - which one was better? Well, I'm still deciding that. By using the node method I can easily expose it in a view. I am not sure I can using custom schema (I think someone told me I could but I haven't tried yet) - I'd really like to use Views for it, and be lazy on the delivery side of it. By going custom, I track only what I want in the database and save probably many levels of pre- and post-processing on the result set.
Getting back to my original statement - Drupal's foundation is pretty solid. It enables anything to be accomplished, it's just that damn middle layer that I wish would be more decoupled and moved into modules that can be enabled or disabled. For the most part, people who use Drupal seem to use it mainly for it's CMS/"Content Management Platform" capabilities just fine. Some of my sites require custom work though, and that is where I enjoy the framework/platform's underlying capabilities.
Typically when developing a site, there are common elements such as user login/registration/roles and management, form processing, XSS/CSRF/other attack vector protection, output encoding, data and request normalization, etc. I've built my own little library of functions and even a bit of a stub framework to use them which do a lot of this. Drupal however has already generalized most of this and provides it to you for no cost.
Frameworks in the typical definitinion such as RoR, Symfony, and half a million others give you the basics, but don't give you that much. It's still up to you to create everything else. While I may whine about Drupal's content-heavy core packaging, it does provide some built-ins that I do find useful to be included. So I guess that can be chalked up to some personal opinion - I would rather the it push the content stuff out to modules (and strip nodes down to even simpler basic structure) yet keep the user registration, login, role and capabilities and form processing available.
All in all, I am having fun looking through the directories of modules out there, and trying to approach things with a more Drupal-eqsue model in mind, understanding that I will sacrifice some performance and add some overhead, but also save myself the headache of all those tedious user submission and form processing screens and such. That's usually where typical self-coded projects seem to start trailing off for me, is winding up getting into the user interaction piece of it. Database design, delivery - that's easy. Form processing and user experience? Annoying as hell 🙂