Design patterns are tools. Like tools, there's two ways to use them: the correct way, and the incorrect way. For example, if I give you a screwdriver and a nail, and ask you to join two pieces of wood together, you should ask me for a hammer. Hammers are used for nails, while screwdrivers are used for screws.
Too often, a design pattern is advertised as the One True Way, which is often only true when particular problems arise. Junior developers are often like children when they find something new to play with; they want to apply that design pattern to everything. And there's nothing inherently wrong with it, so long as they eventually learn that Pattern A applies to Problem B, and Pattern C applies to Problem D. Just as you don't use a screwdriver to drive nails, you don't use a particular pattern just because it exists; you use the pattern because it's the best (known) tool for the job.
The flip side of patterns are anti-patterns. Things that have proven time and again to be bad, usually in terms of execution time or memory. However, both patterns and anti-patterns do no good to the developer that doesn't understand why they exist. Developers like to think that what they're doing is new and inventive, but most of the time, they're not. It's likely been thought of before. People before them have created the patterns because of experience.
Of course, junior developers often seem to come up with new ways of doing old things, and sometimes those ways are better. However, too often it ends up being a case of the Dunning-Kruger effect; the developer knows just enough to make a functional program, but doesn't understand their own limitations. The only way to get past this seems to be through experience, both positive and negative. They ignore patterns because they believe themselves to be superior, but don't know that, in reality, 10,000 developers have already used a specific design, and then discarded it because it was actually bad.
Agile favors "getting things done responsively" in regards to rapidly adjusting to evolving client needs. It neither favors design patterns nor despises them. If a pattern is the fastest, most reliable method, then the developer should use it. If a particular pattern would cost more time than simply "getting it done," using something that's not-a-pattern is likely okay (assuming, of course, that performance isn't severely degraded, etc). If no known pattern can be found, designing their own is preferred over telling a client "no." Clients, especially paying clients, are usually right.
Anyone who claims that patterns are The Way, or claims that patterns are The Bane Of Existence, are wrong. Patterns are tools, meant to be applied to specific situations, and have varying degrees of success based on circumstances. This is a Truth, one that doesn't depend on if you chose MVC or not, if you use Data Transfer Objects, or not, etc. What matters is implementing code in a reasonably short time frame, that performs reasonably well for users, and is reasonably free of logic bugs.
Usually, patterns will allow a coherent form of design, and will perform better than ignoring all patterns in favor of writing 100% original ideas, but you can't avoid all patterns. For example, if y = x + 5, are you really going to write y = x + (5 * 3 + 15 / 3) / 4, just to avoid the pattern of writing x + 5? No. You're not. You're going to write y = x + 5, and move on to the next problem.
People use patterns every day, and that's okay. What matters the most is having code that's logically functional, rarely crashes, and is user-friendly. Nothing else matters more than that.