As architects we try to look for the simplest solution to a business problem.  This is not just because we are lazy, but because simple solutions are easy to maintain and tend to be less tightly coupled.  This does not mean that the simplest solution is always the right solution.  If one aspect of a business requirement can be addressed by a pattern but it invalidates three related business requirements then it is the wrong answer no matter how simple it may be.

In the end it boils down to coming up with a design that takes into account the correct amount of scope and fits the users needs.  After all, it may build our egos to say that we can make a program in one line of code, but if it leave the business stake holders with a view of only half of their process then it is doing more damage than good.  Verifying your business requirements and putting them at the center of your design process is key to success in your project.