I have been presented with relatively straightforward CMS site concepts and come to the conclusion that they would be better done in Rails or Django than Drupal because a) it would be easier to present a usable interface, and b) those would actually be less likely turn out looking like a tower of paperclips and bubblegum.
This may just be my lack of experience in Drupal talking (I've got plenty of experience in PHP, just not Drupal), but I put a pretty decent amount of thought into the matter and even mocked up simple prototypes just to see if there was something I was missing.
The big difference is that in Drupal it's possible to get pretty far without ever writing a single line of code, even templates. For some use cases that's very powerful, especially an environment where you have trainable, reasonably technical people who aren't programmers.
But for the talented developers and/or programmers on the team, it's a complete productivity and sanity drain. Moreso if you're, say, part of HN's target audience, because you'll know all the modern web development techniques, and you'll be able to use none of them.
I have had an absolutely terrible experience with it, which sadly isn't unique amongst these big PHP projects.
It's not bad once you get your head around it. Sure, it's not buzzword compliant (MVC, TDD, ORM OH MY!) but for what it is, it can be pretty compelling.
My primary job for the last 2 years has been developing a Drupal site for a group of daily newspapers with monthly page views in the low 8 figures.
We were in a situation where we had to get a site up quickly (Our small group was bought off from a much larger conglomerate, so the huge $$$$ Java system we had been using
went away). Drupal allows us to get a tolerable site up in about 3 months, and a much better site up about 6 months later. Have there been pain points? Sure. But if we'd used anything else there's no way we would have been on our feet nearly as quickly.
Are we investigating other options? Of course, if I wasn't I wouldn't be doing my job. There's a part of me that would love to rewrite the whole thing in Rails or Django. That would be a huge undertaking though.
I really don't doubt that for many people it has its place, as evidenced by your experience, but the moment you want any semblance of interactivity (at which point you can argue that a CMS is the wrong tool for the job) or efficiency/optimisation, you're screwed.
We've had different experiences, but I wouldn't touch it with a 10' bargepole, not any more. And I'm glad I've been managing to encourage my boss to start moving away from it. The only positive thing I've been able to take from it is a list of things never to do in my own code.
Like I say, it's not just Drupal. It's a side-effect of over-complication in the name of simplicity, and trying to run in parallel a system that makes it easy for non-devs to use. It's a recipe for disaster if you want lean, maintainable code.
Depends. We serve ~40 PHP requests a second (and that's NOT counting stuff that hits the cache) on reasonable hardware - an 8G webserver VM, and a 4G DB VM, both with 4 cores allocated, and hot copies of each for failover. Our site is pretty interactive, and even the stuff that's cached is short (5 minutes or less) timeouts.
This may just be my lack of experience in Drupal talking (I've got plenty of experience in PHP, just not Drupal), but I put a pretty decent amount of thought into the matter and even mocked up simple prototypes just to see if there was something I was missing.