The entire concept of design patterns, really. While I'll admit their book is widely misunderstood, and they address a lot of my concerns in the first few pages, the negative impact the book has had on software can't be overlooked. From the rampant misuse of patterns to the countless over-engineered systems they've inspired, their influence has caused far more problems than it solved.
The general understanding of design patterns is a problem as well. While broadly misunderstood as a 'language of design', the so-called patterns are not language agnostic. The explosion of 'new patterns' that followed further diluted any possible value that concept offered. Just replace the word 'pattern' with 'solution' next time your read about a pattern and you'll see what I mean. (That all stems from the *title* of the book! I've never seen a book's title alone cause so much confusion and harm.)
A note on that misunderstanding: The 'why' is often far more important than the 'what' when communicating with other programs. To say 'I used the visitor pattern here' gives you the 'what', but not the 'why'. There's also a strong indication there that the code is too complex to understand without hanging a common name around its neck.
Moving on... Sploski offered two points, to which I agree: 1) Patterns introduce unnecessary complexity. 2) Recurring use of patterns indicates a deficiency in the language. (There's also a discussion on c2 somewhere about that.) On (1) there's the use of patterns where far simpler solutions are more appropriate. They're often used here because too many developers think that using patterns mean their code is 'adheres to good principles of design'. This leads to a consequence in (2), related to my point that patterns are not language agnostic, which is the amazing amount of effort placed in to implementing patterns in languages that have no need for them.
So what about the premise? Are there, in fact, recurring design patterns? We'll never know. The GoF based their book on good feelings and personal experience, not actual research. You'd think if there were recurring solutions to common problems, they'd have been discovered -- though they're often simply invented, just like those in the book, by every neophyte developer out there. It's no wonder, then, that the term 'anti-pattern' found its way in to our vocabulary to combat the pattern explosion. I've even seen many of the GoF patterns described as anti-patterns. Being groundless, they're vulnerable to such subjective criticism.
Obvious questions like 'is this a recurring problem', 'is this solution effective', and 'is this solution efficient' never seem to enter the discussion. Without a lot of effort, you can't even begin the answer the first question, let alone start proposing solutions! Lacking actual research means that developers have no choice but to actively look for opportunities to use patterns (leading to pattern abuse) rather than simply determine if a particular pattern is appropriate based on the information they have available. That is, they can only ask 'can it be used' not 'should it be used'.
Patterns are folk wisdom, not engineering, and suffer the same problems. Next time you reach for the GoF book, ask yourself if you're putting butter on a burn.