I've found the Net Objectives' method of thinking about patters as most beneficial. People reading the GoF book too often begin to assume that the structures they show, in design notation and in code, are the patterns and that this is always how they look. There's a different, arguably better way of looking at it.
Patterns are sets of similar problems that can all be solved with certain, abstract formulas, not sets of formulas that can be used to solve various problems. What this means is that the pattern is already there before you even begin trying to make a design, the object then of the designer is to find it, not to impose it.
Further, a lot of people look at patterns and say, "Oh, I just solved that by .... I didn't use no silly patterns." The thing is that "...." almost inevitably describes AN implementation of a given pattern solution. For instance, an array of function pointers could serve as a Chain of Responsibility even though this is not what the traditional recipe looks like.
With this in mind, the focus in your study of patterns should be on the problems, not on the patterns. Learn the motivating factors of patterns and how they address those factors. Doing this will allow you to see the patterns in the problem and then simply point them out. This, along with the language that patterns gives us for speaking about design, allows you to expose a design well suited to answer the various difficulties you're currently facing.
YES, in short, learning patterns is not only well worth it...you limit yourself by NOT learning them. I don't want to have to describe all the motivating principles and general shape of solution when I say, "Looks like a visitor to me."
Here's their website: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page