This is a great resource, but I suspect it will soon become overwhelming. There are an infinite number of anti-patterns. There may also be an infinite number of good design patterns as well. But just as y = x, and y = x^2 both approach infinity, one of those formulas approaches a lot faster. The number of bad design patterns out there to look at is just staggering. For anti-patterns to be useful to study, there would have to be some ranking based on how common they are. Otherwise, studying the one or two "right" ways to solve your problem seems like the only practical way to go.
Regular patterns are usually matters of intent—being able to say "this code should have patterns X, Y, and Z" doesn't help you at all if those patterns aren't coherent to the goals of the code. However, "this code shouldn't have patterns X, Y, or Z" is useful, and therefore could be made to be checked automatically. Anti-patterns would then become like virus signatures in a codebase, found during compilation.
I think this could be condensed somewhat. For example, the Jumble seems similar to Big Ball o' Mud, while Junkyard Coding, Stovepipe, and Rube Goldberg Machines all share characteristics.
I'd also like to see design/programming patterns distinguished from organizational patterns like Empire Building or Hero Culture (though not surprisingly, they tend to be correlated with each other.)
Regarding the commonality of these patterns, having worked in an Oracle environment for a while, the ones I see most often seem to be Stovepipe systems and Big Ball of Mud. SQL in particular tends to force a stovepipe approach, because if you try to hide too much complexity behind nice PL/SQL interfaces, you tend to get highly suboptimal explain plans, and/or, you end up losing advantages of multi-block I/O and batch processing. So, instead, you have huge multi-table joins that are inherently brittle and difficult to maintain but which perform adequately. (Yes, views can help here to some degree.)
Because you don't have many clean interfaces, refactoring becomes more difficult and you also get tons of copy/paste code, resulting in an eventual Big Ball of Mud.
See my other comment on how anti-patterns are supremely useful when you're working in a brownfield (existing subpar codebase, project, etc.) and you need to recognize the problems and having suggestions about how to fix them is very helpful.
The key here is to take the approach of the invaluable anti-patterns book and apply your recognition of an anti-pattern into how to refactor it into something better (or get the hell out if you can't).
It's also worth noting that greenfields projects tend to be rare in our field, more often you're starting with an existing brownfield code base. GoF addresses the former, anti-patterns directly address the latter, although it's of course useful to know about anti-patterns so that you can avoid falling into them when you've got a greenfield to start with.
Especially since, in my experience, you're more likely to come across anti-patterns than proper design-patterns. It is nice, though, to quantify the idiocy with succinct names.
