Challenging Patterns
A pattern is meant to be a common solution to a common problem. Thinking in terms of patterns can be a good way to think (and talk) at a higher level of abstraction, so they can be good. One major problem with patterns though is that they're always taken as gospel, as if they are The Correct Way, and they shouldn't be questionned. Just because some pattern has a name and a standard implementation does not mean it's a "best practice".
Solutions Searching For Problems
It's a shame that patterns are named and cataloged only by what they are and do rather than by the problem that they're intended to solve. This has a tendency to create a solution-in-search-of-a-problem mentality which can cause patterns to be implemented in places where they're not the best solution. The problem needs to dictate the solution, not the other way around.
If you have a problem and you know of a pattern that solves it better than anything else you can conceive, then by all means use it. Conversely, all patterns should be avoided unless they can be proven to be better than all other conceivable solutions. Any pattern is the wrong solution if it's not the best solution to the actual problem.
In general, if you're not sure if a given pattern provides a solution that fits your problem, forget you ever even heard about the pattern and just write the solution from scratch. You may find yourself eventually converging on a rewrite of the pattern, but more likely you'll come up with something better suited to your particular needs. Most of the famous named patterns are really not all that revolutionary.
Three Cheers for Java
Secondly, patterns are often language-specific. Because patterns are "solutions", and different languages have different capabilities and deficiencies, the patterns that are relevant from one language to the other are different. Most of the famous named ones are from the GoF book and are thus Java-centric.
What that means is that they may or may not be useful in another language. Some of them really are not. For example, what use is the command pattern in a language with first class functions, closures, and the ability to pass functions as parameters?
Also, there are cases where a pattern is useful in your language of choice, but its prescribed implementation is different or entirely unnecessary. For instance, python has decorators as a language feature, so some implementation of the Decorator pattern is simply obsolete.
Unquestionable Code
Thirdly, who's to say that the original author of the pattern isn't just wrong? We're in real trouble if we start believing some programmer is infallible, even the ones we know to be better than us.
Patterns, like any other code, should be challenged as much as possible for your given problem in your given environment, and they should be used only when no better option is available.