To be specific, the right argument of the in/not in operator must be statically known at compile-time when used in guard position, so you cannot do something like:

l = [1, 2, 3]
case 2 do
  b when b in l -> b # Fails compile with an ArgumentError
  _ -> nil
end

This is because in guard position the in operator works differently than in non-guard position (I really dislike inconsistencies like this), specifically it gets expanded, so the above example when written like:

case 2 do
  b when b in [1,2,3] -> b
  _ -> nil
end

Actually gets compiled to (you can check with a core erlang dump):

case 2 do
  b when b == 1 -> b
  b when b == 2 -> b
  b when b == 3 -> b
  _ -> nil

EDIT: It also works with ranges:

case 2 do
  b when b in 1..3 -> b
  _ -> nil
end

Gets turned into:

case 2 do
  b when b >= 1 and b<=3 -> b
  _ -> nil
end

case some_value do
  value when value in [nil, ""] -> something()
  _ -> something_else()
end

I think your overall point is good but this is in fact false, both in matches and in the general case:

iex(1)> match?(x when x in [1.0], 1)
false
iex(2)> 1 in [1.0]
false

Ok, then I mid remembered the semantics of in. The issue of bindings still applies and the fact that guards do affect the performance as well. So 2 of 3 issues remaining.

This only works kind of. 1 in [1.0] is true when I’m remembering correctly. Also sometimes you want to bind parts of the different matches. That won’t work with your guard as well. Last but not least guards can’t get compiled into a trie and therefore slow down the overall match.