Coming back from vacation I saw that Jeff Atwood (coding horror) wrote a post on "rethinking design patterns"
a few days ago. Jeff criticizes the GoF design patterns book
Jeff says his two main grips with the book are

1. Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.
2. If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering-- it's a sign that your language is fundamentally broken.

I agree that these can be a problem with using design patterns in general and the GoF ones in particular. I would add to this that I think that using design patterns just to be able to say you've used them is very wrond as well (this may sound obvious - but I have seen organizations where this was encouraged).

I don't think however, any of those problems are problems with the patterns themselves. This is not to say that the GoF book is perfect.Looking back at the GoF book I think that it isn't clear of problems. For instance, I don't think all the patterns stand the test of time. The most prominent example for that is the Singleton pattern, which I hardly recommend using these days. Singletons are problematic for testing and  create a tight coupling for a specific instance. There are better ways to create a mono-instance if that's what you need (I think others have posted about it in the past - but I can post about it separately if needed)
Also, newer languages sometimes provide better ways to tackle some of the design patterns solutions - see for example a recent post by Alex Miller where he talks about an alternative for Template Method.
I can even say, that not all the patterns are that useful (Flyweight comes to mind as an example).

Nevertheless, I still think that the GoF book is one of the most important books in computer science. First it is a seminal work which introduced the patterns thinking into software development. Today we have literally hundreds of patterns on all subjects and technologies. I think it is a very good think since the looking at a problem from a pattern perspective gives us more depth and understanding on both the problem and the solutions vs. other ways I've seen.
Even in itself, the GoF book is great, since many of the patterns are very valuable and can help us solve real problems. we just need to keep in mind that the sample implementation in the book is just that - sample. There can be more than one way to code a pattern and still gain the benefits (these are "design" patterns not "coding" patterns). A few weeks ago, someone asked a question on the visitor pattern in one of the forums I monitor. The guy needed to add an additional parameter to the Visit method and asked if it wasn't a violation of the pattern. I told him that there isn't such a thing as "violating a design pattern". The patterns are a means to an end not some coding codex we should keep. I think, that if we treat the design patterns as pieces of knowledge
rather then a holly script, they can really help avoid some stupid mistakes.

Thus, at the end of the day, I still think the Gof book is required reading for any new developer. But hey, that's just my .2 cents :)