Yes, patterns are essential. I'll refer you to What if I will not use Software Design Patterns? by Eric Lippert in which he points out:
Variables are a design pattern.
Methods are a design pattern.
Operators -- addition, subtraction, etc -- are a design pattern.
Statements are a design pattern.
Values are a design pattern.
References are a design pattern.
Expressions are a design pattern.
Classes are a design pattern.
Everything you do in programming at all times is a design pattern.
Most of the time the pattern is so ingrained into your thinking that
you've stopped thinking of it as "a design pattern". The things that
you have to learn like "the singleton pattern" and so on are simply
patterns that haven't (yet) been baked into whatever language you're
This goes to your point of that you've used design patterns without even knowing its name. You've also used ones that you did know had names but didn't realize they were patterns.
The key is how people think about patterns... and to an extent I blame education (or maybe the lack of) at times where they expect Design Patterns to be like Legos - "we'll get a Abstract Factory, and Flyweight, and a Singleton and a Facade... and it will all just fit together." One can often see this in questions asked "What pattern do I need for problem XYZ" before they've really started coding or thinking about the project as a whole.
Looking at the original book A Pattern Language (wikipedia) about building architecture, a Pattern is something that you use to solve a particular design. You want to put a window in a stud wall? Well, then you put in some cripples and a header and a bottom plate and so on (wikipedia). This is a pattern and you do it because you want to put in a window in a wall.
Note that in the above example, the problem came first, then the design pattern. I need this, this is is how I'll fix it. The other way around "I'll put some cripples, bottom plate and so on here so that I have a window because I'll need a window" is the wrong way to go about the pattern of a window. Likewise, it's the wrong way to go about using patterns in software development.
The other thing to realize is that if you have two people working on putting in a stud wall, they can quickly communicate and understand what is going on when they put in a window. They both know and understand the problem and the pattern and how to apply it. The same is again true with software. We've got a problem that we need too many Integer objects being created? We'll put in a Flyweight. And thus, two programers have communicated, and know how to solve the problem because they are able to speak of Patterns.