What I also noticed while tinkering with Drupal: unlike WordPress, the database model is quite complex. WordPress is pretty straightforward - just a few tables with data in them, most of it quite straightforward. If you want to change something, you can always fiddle with it at the SQL level and write import scripts, repair scripts, etc. Everything is always calculated on the fly - counters, lists, etc.
Drupal, on the other hand, uses quite elaborate caching mechanisms in the database. Things from the filesystem are also cached. This means that with small scripts you have more work to do, because you have to account for much more - at least remove the cache so it gets reconstructed. Also, the data model is much more denormalized. That's certainly good from a design perspective - but for small scripts it's more cumbersome, since you have to handle more places.
This is now not a judgment, just an observation - both have advantages and disadvantages. The advantages of the Drupal approach seem to show up in performance, which seems to be somewhat better than WordPress not only because of the somewhat cleaner PHP structure (though I don't have hard numbers on that - first I need a workable import script for my posts to work with the same approaches).
What I also noticed: PostgreSQL support in Drupal (yes, I finally got it running!) is definitely behind that of MySQL. In some cases there are error messages with PostgreSQL that don't occur with MySQL. For example, there were problems with password changes because a non-existent field was being accessed. Or in the overview of sources subscribed to in the newsreader there was a message because a non-aggregated field of a complex SELECT was not listed as a grouping field. Or on first access, where no value was specified for the uid field in the sessions table, even though it was declared as NOT NULL. PostgreSQL is definitely more picky than the card file. With PostgreSQL you'll definitely have to modify the PHP code. I'll see - once I'm done, maybe I'll prepare a patch that fixes these issues. So far they're just minor things, but they can certainly be a hurdle for non-programmers. Some of them are certainly based on the somewhat older versions from Debian Stable (for example, the PgSQL API in PHP is named quite differently in newer versions than in 4.1.2).