In non-trivial cases, these are still useful patterns though in many languages. E.g. traversing a complex AST is often an ideal case for a Visitor. Builders are useful e.g. you want to validate relationships between objects, so you keep a hashmap while building so you can do O(1) validation while building and provide targeted error messages, but then throw away the hashmap after building. Builders are especially useful if you avoid mutable state since you can often contain the mutable parts to the Builder and make the built object entirely immutable.
A lot of the patterns are useful, but you would unknowingly "use" them when appropriate without ever having explicitly learned them. E.g. the Adapter pattern is an obvious solution to a particular problem. I think the only contribution the book has for these patterns is giving these names.
It would be easier to identify the ones that don't make sense. The only obvious one is Observer, since without mutable state there's nothing to observe. Everything else looks relevant for immutable objects.
Not saying this is the only way of viewing them; there is validity to both but it is I think it is important to keep in mind that the patterns are also supposed to be solutions and not just the names of problems.
What happens as you move around languages is not so much a binary thing, but the relative importance of them changes. Plus you should expect patterns to appear in a new language that weren't in the old language, both because the pattern would be too easy to be a pattern and too difficult to be a pattern. Some will fade away so far that maybe they aren't useful any more.
I really know someone doesn't get the GoF pattern thing when I see "Design Patterns in X" for X != ["Scheme", "C++"] and they are exactly and only the GoF design patterns, implemented in the target language. That is not what they are for. Generally in my experience they're some combination of "wrong", "unidiomatic", and "not the easiest alternative" in the target language anyhow.
You mean the Strategy Pattern?
A lot of the patterns are still there. They just look very different.
Arguably, Haskell's use of monads is a pattern. It just isn't in the GoF, since it doesn't solve a problem that was a problem for the languages the GoF was written for.