Have you read Design Patterns? The viewpoint you have here is typical of people who have absorbed it osmotically from software culture, but haven't read the work itself. You say:

> Instead the GoF book largely presents a canonical list
> of some design patterns, giving people the false
> impression that these are special and unique versus
> merely a sampling of ways one might do things.

From the Introduction:

"Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too."

> Additionally, the GoF book doesn't make it clear that
> each design pattern exists to work around specific
> constraints, and thus doesn't educate the reader when
> and why the design pattern should be used, and when not.

"No discussion of how to use design patterns would be complete without a few words on how not to use them. Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed. The Consequences sections are most helpful when evaluating a pattern's benefits and liabilities."

Literally every single pattern chapter in the book comes with an explicit section describing when you should and should not use it.

> The GoF list of design patterns is very much tightly
> coupled to the peculiarities of Java at the time the
> book was written. Many of the design patterns aren't
> necessary outside of that environment.

As another commenter noted, Design Patterns is older than Java and makes no mention of it. The patterns are often particular to object-oriented languages, but I don't know what else you would expect from a book titled "Design Patterns: Elements of Reusable Object-Oriented Software".

> Many of the more advanced "behavioral" patterns from
> the book are essentially ways to work around the fact
> that Java didn't have first class function, when that
> changes the design patterns that you end up with become
> very different.

The book uses Smalltalk as one of two example languages. Smalltalk not only has first-class functions, but all blocks used for control flow in Smalltalk are essentially closures.

The Command pattern isn't just "how to take first-class functions in a language that doesn't have them". It also talks about commands that are undoable, or that can be logged, or serialized and deserialized. It's as much about the objects that create the command, receive the command, and have the command invoked upon them as it is the command itself.

I do wish it talked more about the relationship between commands and first-class functions (which I do here[1]), but it's not as bad as you make it out to be.

[1]: http://gameprogrammingpatterns.com/command.html