I'm a fan of patterns.  I think of patterns simply as problem and solution pairs.  I wandered by The Hogg Blog and noticed Jason's post on The Great Debate: Patterns vs Tooling.  Since patterns and tooling both have their place, I think there's less of a debate and more of a gap between state of the art and state of the practice.

Why Patterns
I think patterns are an efficient way to share insights.  Consolidating 100's of words down into a few is pretty powerful.  A pattern language is a great way to map out the terrain of a domain.  I think of the pattern language as a constellation of meaningful nuggets.  I think the most insighful nuggets are the ones that help you with the toughest forks in the road.

Patterns in Practice
While working on our security and performance guidance, our team was able to rapidly solve and share end-to-end solutions for incredibly complex application scenarios.  As we worked through customer scenarios, we would pattern match against our deployment patterns and application infrastructure patterns.  To put this in perspective, I remember a customer that had been prototyping a solution for six months, that we solved in ~3 hours because we had a collection of patterns to draw from.  We got to a vantage point where we could solve some of the toughest architetural issues for customers in a few minutes.  Looking back, I wish we had a more agile way for sharing our learnings with more customers, and I think patterns and pattern languages could have been part of the answer.

Key Usage Scenarios
There's lots of uses for patterns, but here's some examples:

• Building vocabulary.  A lot of light bulbs went off for me when Ward pointed out that patterns help build a shared vocabulary.  It's a way to talk about our craft and to hand knowledge down from one generation to the next.
• Sharing solutions.  This is what patterns do best.
• Encapsulating principles.   It's one thing to talk about a bunch of underlying principles.  It's another to have a nicely named pattern.

Key Issues with Patterns
Here's some of the issues I've run into with some patterns and repositories over the years:

• Problems solved.  I don't tend to see enough patterns around the more interesting, engineering problems where patterns are worth the effort.  I think quality attributes are great candidates for patterns (security patterns, performance patterns, reliability patterns, flexibility patterns ... etc.)
• Locked in print or teasers to more.  A lot of the most insightful patterns are locked in print.  It makes it tough to share, particularly when we don't all have the same bookshelf.
• Bad organization.  I've seen only a handful of pattern libraries that impress me.  I'm not saying they don't exist, but that I haven't seen a lot I like.
• Relevancy.  I think one of the biggest issues is just finding relevant patterns for your problem at hand.  No matter how well a library of patterns is organized, it still helps to have a shepherd.  Web 2.0 can help here.
• Bad templates.  Sometimes the structure of information is as important as the information.
• Bloat.  Blah, blah, blah.  I'm not a fan of verbosity when I need to get my job done.  I've seen some patterns that were more complicated than the solution they were describing. 
• Vocabulary.  While patterns can help build a shared vocabulary, it can be tough in the beginning, like learning yet another vocabulary.  Convergence takes time.
• Silos and pockets of insight.  I don't think patterns are as prevalent as they could or should be.  I find a lot of the best nuggets are spread a great deal over time and space.
• From concept to code can be a big jump.  Sometimes you can't get there from here, or it'a a painful process.  I think this is very much a tooling opportunity.
• Silly or make-believe patterns.  I've come across a lot of patterns that seem to be patterns for the sake of patterns.  Ward always told me that the best patterns tell you something you didn't expect or that surprised you.
• Lack of anti-patterns.  I actually think there's not enough anti-patterns.  While there's more than one way to solve a problem, sometimes there's a few places you really shouldn't go, and that's where anti-patterns fit in.   Some of the best security insights are documented as anti-patterns.

Key Opportunities for Patterns
I think there's more opportunity than ever for building better pattern libraries and leveraging social software scnearios and tooling opportunities.  Here's some examples:

• Guidance Explorer.   Guidance Exploer lets you easily cross-link patterns or link them to other items.  For example, imagine a pattern that links to a code example or a how to or a set of guidelines and checklists.  We've also played with the idea of showing patterns as mind maps so you can see the related patterns.  Guidance Explorer can also help solve the relevancy issue, by providing more fine-grained organization, as well as make it easy to build a collection of the ones you want.  All we have to do is fill up our pattern node with a critical mass of more useful patterns.
• Web 2.0.  I think Yahoo Design Patterns is a good example.
• Tooling support.  I'd like to see more drag+droppable patterns and pattern-based modeling going forward.

My Favorite Pattern Guides
Here's a few of the pattern guides I've found to be useful:

• Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
• Patterns of Enterprise Application Architecture
• The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience (if you build Web apps, this is a MUST read)
• Head First Design Patterns (Head First)
• J2EE Design Patterns Applied
• Java 2 Performance and Idiom Guide
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series)