Design patterns can help a team by facilitating high-value communication about design.
It's an ancient idea. Carpenters have named all the different kinds of joints. A carpenter doesn't tell another carpenter "use this series of cuts and then attach two pieces of wood in this way". They would just say "use a bridle joint for that".
Sewing has different kinds of stitches. Sailors use well-defined knots. Storytellers know about tropes and cliches. You'd be hard-pressed to find a vocation requiring any skill at all which hasn't identified recurring problems, associated them with common solutions, and assigned names to make communication easier.
This is one of the functions served by design patterns in software. Two developers with a strong understanding of what, say, the Command pattern means are able to very quickly discuss problems that involve decoupling the decision of what to do from when and/or where it is done.
Each pattern represents an high-level concept in a shared language. The broader the understanding of that pattern within a team, the more effective the language. The more patterns understood, the richer the language.
A team that uniformly understands basic patterns can quickly collaborate on solving the most common problems. A team that goes further can have sweeping, meaningful conversations about large, complex problems in a very short period of time.
