For consistency, the same design problems should have the same design solutions a.k.a. pattern. If you don't value consistency, feel free to take a different approach every time. That will confuse your users. I used to work with a guy, the simple problem of reading a CSV was done using a library, problem sorted. Out of sheer excitement he then rewrote it was with combinator parsers, then as some astronaut architect functional monstrosity, so complex no one else could comprehend it.
This is how not to do it – for same problem, use same solution. I admit that's an extreme case but it's also a real one and illustrates the issue well.
(also patterns are not specific to OO, nor is OO incompatible with a functional style)
Are you replying to the right person? I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book[0], not that patterns are inherently bad!
This is how not to do it – for same problem, use same solution. I admit that's an extreme case but it's also a real one and illustrates the issue well.
(also patterns are not specific to OO, nor is OO incompatible with a functional style)