It's certainly worthwhile for every programmer to read Design Patterns at least once, if only to learn the shared vocabulary of common patterns. But I have two specific issues with the book:
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.
Although I have only read the Gang-of-Four book I guess those statements can be seen as general issues. I kinda disagree with both of them.
I agree as far as design patterns do add complexity. The difference between complex code wrapped as a design pattern and unstructured code is that you know how to handle the design pattern like code. You know what it's supposed to do and what you can expect when you use that junk of code.
The boilerplate code issue can be tackled by frameworks and tools. State of the art IDEs are able to refactor your code to patterns and reduce the amount of boilerplate code you need to write by yourself.
I agree that if design patterns are overused or applied in a wrong way you'll end up with a bigger mess than without them.