It's both.

The *concept* of patterns makes sense. A shared language that developers can use when building things.

The *reality* of patterns has been much less useful. The original ones were indeed a reaction to warts in the popular languages of their era. And as we tend to do in our industry, these have been cargo culted along the way and for some reason I still see people talking about them as first class citizens 30 years later.

People don't seem to realize that patterns should be and are fluid, and as our industry evolves these patterns are evolving as well. A major difference between software engineering and the analogous fields people use when talking about patterns is those industries are much older and move less quickly

Since a single-method object easily serves the role of such a function, that’s simply not true. Looking at the 23 GoF patterns, I can’t identify any that would be obviated by having first-class functions (or lambdas, as many OO languages nowadays have). Some of the patterns can employ first-class functions (e.g. an observer could be just a callback function reference), but the pattern as such remains.

The language feature isn't "passing and returning functions" but "loose coupling." Lambdas and Functors are just a way to represent that in OOP languages that care more about inheritance than about messaging.

A lot of patterns have become frameworks, or language features, yes. It's just paving cowpaths.

Are you referring to function pointers?

I believe C has allowed passing and returning functions from... the jump, no?