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