I saw the answer to this question: How does thinking on design patterns and OOP practices change in dynamic and weakly-typed languages? There it is a link to an article with an outspoken title: Are Design Patterns Missing Language Features. But where you can get snippets that seem very objective and factual and that can be verified from experience like:

PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp."

and a thing that confirms what I recently seen with people trying to simulate classes in javascript:

Of course, nobody ever speaks of the "function" pattern, or the "class" pattern, or numerous other things that we take for granted because most languages provide them as built-in features. OTOH, programmers in a purely PrototypeOrientedLanguage? might well find it convenient to simulate classes with prototypes...

I am taking into consideration also that design patterns are a communcation tool and because even with my limited experience participating in building applications I can see as an anti-pattern(ineffective and/or counterproductive) for example forcing a small PHP team to learn GoF patterns for small to medium intranet app, I am aware that scale, scope and purpose can determine what is effective and/or productive.

I saw small commercial applications that mixed functional with OOP and still be maintainable, and I don't know if many would need for example in python to write a singleton but for me a simple module does the thing. patterns

So are there studies or hands on experience shared that takes into consideration, all this, scale and scope of project, dynamics and size of the team, languages and technologies, so that you don't feel that a (difficult for some)design pattern is there just because there isn't a simpler way to do it or that it cannot be done by a language feature?