Perl's philosophy tends to be that of "do what is practical now." If you need to use OOP, its there. It isn't necessary in all solutions and forcing a person to write OOP code when it is a simple "do this then this then this" type problem is often counter productive.
The multi-paradigm nature of perl can be seen in things such as the Schwartzian transformation which has very functional aspects to it (in Lisp it is known as "decorate-sort-undecorate"). OOP exists, as does procedural (C like programming) and imperative (bash like "do this then this").
Design Patterns are reoccurring solutions to common problems. They exist in every language. Sometimes these patterns are called idioms, though this may also refer to things that are much more simple than a pattern.
When necessary, many of the classic GOF Design Patterns can be implemented in perl. Perl Design Patterns will have many common names that people familiar with the GOF. It isn't necessary the case that all of them are idiomatic perl.
When exploring design patterns in perl, please also take note of "Design Patterns" Aren't by Mark Dominus.
Many consider that the Design Patterns are deficiencies in the language. In that perspective, Design Patterns such as the Iterator are often unnecessary in perl. Not always - but often.
First, write idiomatic perl. Don't try to write C in perl, or lisp in perl, or java in perl. Perl is perl. If there is a problem that gets bigger than idiomatic perl can handle and you start needing more complex class structures, then write them. Know the design patterns to be able to recognize "this problem has now grown to the point of needing an abstract factory" - but don't start out trying to make an abstract factory in perl if you don't need one.
Some libraries exist in both OOP and more traditional forms. See Should I use the function-oriented or object-oriented CGI interfaces? for an old SO question where one asks which way to use the library.