try this

list.removeAll(Arrays.asList(2));

it will remove all elements with value = 2

you can also use this

list.remove(Integer.valueOf(2));

but it will remove only first occurence of 2

list.remove(2) does not work because it matches List.remove(int i) which removes element with the specified index

Typically, people remove things from lists already knowing what those things are, as that knowledge is why they want to remove the item in the first place. By contrast, people don't usually want to remove specific known items from a stack/queue, but rather retrieve the first/last element.

Probably relevant factors:

1. Consistency with List<T>.Remove(T).
   A List<T> has a .Remove(T) method that returns a bool indicating if the removal was successful. So, for consistency, we'd expect .RemoveAt(int) to do the same. Except .RemoveAt(int) can't really fail (unless the index is out-of-range, in which case it throws an exception instead), so it just returns void instead.

2. Removing an item from a list doesn't imply retrieval.
   Queues/stacks are all about specific process models in which things are queued/stacked and then dequeued/popped for processing, such that removal and retrieval are conceptually linked together. By contrast, lists don't inherently imply such an operational model.

3. Retrieval is readily available for when someone would want it.
   If a caller would want to retrieve the item at the index before removing it, then they can just specify that with list[index].

It's worth noting that a hypothetical ConcurrentList<T> would've probably implemented

partial public class ConcurrentList<T>
{
    public bool TryRemoveAt(
                int targetIndex
            ,   out T successfullyRemovedItem
        )
    { /* ... */ }
}

, analogous to a similar .TryRemove(T_Key, out T_Value) for ConcurrentDictionary<T_Key, T_Value>'s.

Finally, the main use-case of List.RemoveAt() is probably something like:

for (int i=0; i < list.count; ++i)
{
    if (someConditionalCheck(list[i]))
    {
        list.RemoveAt(i);
        break;
    }
}

, where it's important to note that break;, since if the loop continues without breaking after removal, then it'll skip an element. This could be fixed by also manually decrementing i, e.g. --i instead of break;, but at that point the code's getting pretty twisted. Plus it'd be poor form to try something like this without a break;, anyway, as list-removal is O(n), making it a poor choice of data structure to use if someone expects to loop over multiple removals as that could be O(n²).