It really depends. If under the guise of "best practices" and "patterns" a team creates an unmaintainable, not easily extensible mess, then all this community aspect was good for exactly nothing but shoulder patting. If instead pattern are used sparingly, where they actually make sense, then sure, it can help.

We need to keep in mind, that the most composable concept in computer programming is the pure function (or maybe a mathematical "relation", if we want to abstract further). Not a mutating object. Not some constellation of objects that constitutes a pattern. Those are merely special cases.

I am currently developing a GUI application. Most of the classes in my code are classes, that are custom widgets. The GUI framework is OOP, so that is kind of infectious for the rest of the code. Still I try to keep some stuff separately as pure functions. Probably will outsource more stuff like that into completely self sufficient functions. The only pattern I have so far in the whole application, is a mediator, which I use as a way to have objects register themselves as listeners to specific events and for other objects to send these events to anyone who will listen. That way objects don't need to know, which other objects are interested in learning about some event. Could I have built in some factories and whatnot? Surely I could have, but there would have been very little, if any benefit. Even the mediator only exists, because the GUI framework does not have a way to send events that include data, so I need a way to do that. Otherwise I could even get rid of that pattern as well.

In this way pattern are useful for when you really need them, but these OOP pattern by themselves, without context, don't really have a value. No code becomes better by building in more patterns, unless the situation requires such a solution.

I think the problem is that people will never agree about the same definitions when discussing complex topics. For example, even when it comes to testing, I find that developers tend to disagree about definitions of 'Unit tests' vs 'Integration tests' vs 'End to end tests'. Some people will insist that a unit test should stub out all the dependencies and if you're testing a module and it invokes some internal sub-module (not mocked), they will insist that it's an integration test... Some people will say it's only an end-to-end test if it includes the front-end as well; other will say that if the test involves interaction with the database or other IO operations; then it can be called e2e.

There are a surprising number of topics; not only in engineering, but in day-to-day life as well, that we tend to think we all understand and have consensus about, but in reality nobody agrees on the same thing and there is no real consensus.

People tend to form consensus over labels; not over concepts. They may fully agree over labels but actually fundamentally disagree over the underlying concepts; they only realize this once they start defining their interpretation of the terms.