Your post reads like a mixture of trolling and ignorance. Maybe it's deliberate, or maybe it's a genuine lack of understanding. Let's deal with it point by point...
You should never use it, seriously.
Some users: The White House, The US Dept of Energy, NASA, Stanford Law School, the Grammies, as well as hundred's of thousands of less high-profile sites. Or we could believe you.
It's remarkably similar to early php in being a fractal of bad design.
At the heart of Drupal is a callback system, with registration by naming. This allows code written by different people to interact. Need to do something that nobody has done before? You hook into the data processing by writing a function with the right name, and return the result of your processing. That's with respect to stuff done in code, but you can a huge amount of what you'd like to do using click and point...
One core idea in Drupal is as much as possible to move the ability to do useful design work into the province of administrators. So if you need to record a new piece of info, you click and point, to add a new field to your existing database. Everything is taken care of, and it's immediately useful for storing and displaying data.
I guess you could call this a fractal of bad design if you believed that putting power into the hands of users was irrelevant.
They are slowly trying to improve it, but their attempts at improvements are woeful.
The development cycle runs at around 2 to 3 years for major releases, but that excludes modules, which are the packaged units of add-on functionality that extend Drupal. The last major version was 7 (and Drupal is 10 or 11 years old). The list of things that were added or changed are extensive. In fact this is one of the problems with Drupal - the rate of change can be too great.
Hundreds of tables with the most Byzantine schema you can imagine, even for incredibly simple needs
Yes, Drupal is a general purpose CMS. If you want a single table solution for a particular issue, you are free to write it, using one of the demo modules as a base. It's easy, and this is typically how Drupal in version 4 and 5 was extended, but if you take advantage of the click and point interface you end up with many more tables. You also have content versioning, the ability to have a multilingual site, the chance to add or remove fields from content by pointing and clicking, the chance to represent the content in different ways for different audiences. And more. I wouldn't say the scheme was Byzantine though, it's well documented in numerous places. All it takes is the willingness to read a bit.
Attempts to allow customers to define the db schema by adding fields etc
I guess you believe that customers should not have the ability to control the data they own. Nuff said.
Code in the db - that anyone ever thought this is a good idea is a huge red flag
I'm not sure what you are referring to. Maybe template caching? Maybe callback hook caching? Probably you mean the power user ability to turn on a PHP filter, which will allow PHP code as part of content. This by the way is turned off by default, and when it is turned on is subject to the Drupal permissions system which has fine-grained control over who can do what. Power users sometimes need powerful tools.
Upgrades are often incompatible
If you mean module updates, very infrequently in my experience. If the site you are working on is complex, maybe you need to run a development version too, or upgrade using an automated upgrade system. If you mean major version upgrades then, the promise is that Drupal may break your code, but will never break your data. That is, an upgrade from Drupal 6 to Drupal 7 may require you to rebuild a custom component because of API changes, but will never destroy your data. A major version upgrade happens once every few years, meanwhile two versions of Drupal are active, currently versions 6 and 7, so you are not forced to upgrade.
A horribly broken plugin system and ecosystem,
Well, there are about 20,000 plugins (i.e. modules) at the moment, to use for free, so I guess that neither the plugin system, nor the ecosystem can be 'horribly' broken.
resulting in sites which load hundreds of plugins to support simple tasks,
I think you need to be more specific. Are you saying that a simple task has hundreds of requirements? I've seen very complex sites with hundreds of modules, but no simple sites like that.
and therefore have a huge attack surface
Of course Drupal has security holes, as does all code. And the security team is pro-active, with monthly announcements about problems found. Most people think it follows best practice.
and a huge amount of unmaintained, scarily bad code.
That's not my experience. But it's open source, so if there are problems, then you can find them, and fix them, and submit patches. You can also report problems you've found about 'scarily bad code' to the security team. They'd love to hear from you.
I've seen sites with hundreds of these modules loaded.the learning curve is huge and the code extremely fragile due to the above decisions.
So you are saying that you've seen badly built sites, that you didn't understand. I guess it shows it's possible to make bad choices in any circumstances, with whatever tools you use.
Content is all stored in 'nodes' which are infinitely flexible, and therefore infinitely opaque and difficult to work with.
Oh gosh, that's bad. A flexible system! A bit of learning about how the system goes a long way towards making things less than 'infinitely opaque'. It's not as if you can't find the documentation in books and online.
There are no pros or professionals working with Drupal
Well, I guess I don't count; thirty years of writing software clearly doesn't qualify me. That would include a couple of CMS systems, shrinkwrap software and stuff that's been used and seen by hundreds of thousands of people at the least. And I guess the thousands of people employed by Drupal companies don't count either.
I dread to think what would happen if security professionals looked carefully at many drupal sites due to the above, particularly the modules situation.
It turns out that lots do, and on the whole they are pretty satisfied. Interestingly I know of one high-profile security company using Drupal. You'd think they'd be prime targets.
If you're thinking of using it for a php cms, think again, look at Wordpress for example
Wordpress is a fine CMS, in use by millions of sites. If it suits your needs then you should use it.
And to answer the other accusations variously made in the thread below...
Frankly part of the problem with Drupal is the many people who have invested so much time learning all the unnecessary APIs and working around its idiosyncratic code and db schemas, or fixing upgrades that leave modules behind that they can no longer find it in themselves to suggest the radical improvements required. Drupal is broken, in so many ways, you should at least acknowledge that there are issues if you want to be taken seriously.
No large system is perfect, but this is a huge misrepresentation of the state of the project. Unnecessary APIs aren't used, so no idea what you mean there. Idiosyncratic code? Maybe you mean that Drupal pre-dates most other frameworks? Maybe you don't know that Drupal 8 is using Symfony components? Maybe it means that you didn't understand the way the system worked?
That to me is a big part of the problem with the Drupal ecosystem - unwillingness to listen (even in small part) to quite justified criticism and an insistence that anyone criticising is somehow to blame for the problems they have encountered.
Rofl. I wonder if ever been to a Drupal conference. Seems unlikely. On the hand, perhaps the tone you struck managed to endear you to the people devoting their time and energy for free, whenever you posted a query.
I mean they only just started try to clean up the mess with fields, and to do that they've introduced CCK!
I think you are confused. The Content Creator's Kit (CCK) modules were a Drupal 6 system so that site administrators could extend sites using point and click to add new content types and extend existing ones. The heart of that technology was incorporated into Drupal 7, in a better more flexible way and named Fields. Drupal 8 builds upon the experience of the last few years, and on the base technology of Fields.
Ultimately, the main problem I have with it is a philosophical one though, which has driven a lot of the bad decisions on design: the designers seem to think that end users can effectively specify a complex system involving a db and code, which they only partially understand, through the browser and by choosing modules written by other people.
And there's the heart of it. Apparently you think that only special people should have access to power.
The result is a complex tangle of poorly understood code which interacts in unpredictable ways and tries to be everything to everyone and ends up satisfying nobody's needs very well without lots of extra work.
Yes, guilty as charged. Drupal tries to deal with the common problems ahead of specialised problems. And that's a bad thing how?
That's a discussion made with the understanding of all the things that Drupal does. It doesn't serve to reinforce your various polemical statements very well. It does say that they API to get stuff done has grown considerably. Perhaps this means as well as exposing a low-level API, we need some higher-level functionality. And do you know, as if by magic, this stuff exists too, it's just not in Drupal core yet!
The demo included a massive data migration accomplished with 4 lines of javascript in the MongoDB terminal
Yes, a demo is a prebuilt system designed to work perfectly on the chosen data. That's a neat trick to work perfectly on some prebuilt data.
by comparison, I recently tried to change a dropdown field to a text field (both identical strings in the database) and Drupal told me it couldn’t do that because “the field already had data.”
And yet I just changed from Amazon S3 as a datastorage for some data to my local file system.
All that said, I'm not saying this because I have some axe to grind about Drupal
Lol. I think we can let that speak for itself.