I've been working with Drupal for about six years or so. Like many, I sort of fell into Drupal in the manner by which a lot of us end up aligned with one CMS or another. Meaning, it was a historical alignment rather than an academic one.
Regardless, Drupal is still a good reprsentation of what a CMS can and should be. It definitely has its shortcomings (loading times, come on!), but there's a lot to draw from its architecture and patterns. That said, there's a lot of what both developers and non-tech savy end users mess up as they attempt to get more complex with their CMS. These aren't technical issues so much as conceptual ones.
The System Doesn't Know What You're Thinking
There's this adage in programming - the computer does what you tell it to do, not what you want it to do. With Drupal in particular there are loads of settings, permissions, weighting, and so forth that need to be optimized for your particular site's content. While this can be frustrating, it does just take a little bit of time to get everything in order, however, while a user not being able to see the navbar can be annoying, the most common place I see this issue is with images.
Drupal's fancy image cropping, scaling and processing are awesome, it's one of my favorite parts about spinning up a Drupal site. But what most folks forget is that while it can make everything fit a certain dimension for your design, Drupal doesn't know where your picture looks good. Maybe someday Drupal will be able to find the best cropping of a photo for a thumbnail, today is not that day.
I've seen this in subtle ways elsewhere. For example, folks will develop and complex user system hierarchy, but then not want to manage it, wishing the system would just know where there new users should go. Likewise for node type management, particularly when there are a load of custom fields per node.
You Must Have a System as Well
Drupal is a CMS. It's a system that tries to publish content for you in an organized way. However, your end as a site content producer must be systematic for the site to work well for you. Drupal is not a tack board to simply plop content however you would like on the front page. Having a loose system for how you would like to display, publish and arrange content, while it can be expressive for some content producers, it is also very brittle and the system's liable to break and stumble over itself.
This most commonly occurs in design and in the block system. You'll have a hundred blocks or so that have these extremely specific node listings for display. None of that is fun to maintain and it some point you'll want to toss it all out.
Layout and Content Are Not the Same Thing
This is my personal rule, and I've violated it plenty of times, but at no point should you have these complicated layout fields in your nodes that designated whether something should have a particular background color, text color, width, whatever. All this should be built out into the theme. Content producers are not designers and they shouldn't be forced to make design decisions as they produce content.
Use different node types if the layout is really that complex, but more importantly, Drupal works well with a simple design rather than an overly complex one that ends up sucking the energy out of the site editors as they try to create nodes that just look decent.
Tagging and Sorting Are Not the Same Thing
Drupal's taxonomy system is awesome. It's all you need and just so. As such, the system should not be jimmy-rigged to work with a blending of ordering and of tagging. This basically comes up in situations where you define a list of words like "featured", "top" and such to make things sticky to the top of lists. First off, there's already a sticky feature in Drupal. Second, without a doubt, site users almost always mix up their ranking systems so the content lists don't come out looking as they should.
I always recommend that people use nodequeue or node references if you want to manage specific content lists and let your related content float naturally using some system like publication date. This will typically give you all the control you need without having an extra layer of hassle.
More often than not, developers tend to give themselves trouble by not holding their Drupal implementations to an organization where it will work well. Sure, you can make Drupal do such and such, but often times it's a hack rather than an innovation. While these make-it-work solutions can satisfy you for a short period, they tend to give Drupal site managers and content producers more work.
Best advice - keep it simple. Spend your coding time making good themes, organizing proper Views, and using custom module dev for more complex queries or data entry / processing. If you find yourself spending a lot of time in custom fields, taxonomies or blocks, you may want to reconsider your approach.