The answer is: it depends. In the above usecase it depends for example on how many logins you have per day (how many bits are active in the bitmask). If you have for example 2 logins or random user ids, it might be better to just store an LIST of logins.
But if you are having an active userbase and 60% of all users are active.. it turns out that having to store 1 bit (actually its less than that on average, because redis only stores the bitmask until the heighest set bit (1) is reached) is much more memory-friendly than storing IDs in a list.
Storing IDs in a list will result in the use of e.g. 32 bits (integer) to represent a 1-bit information, which is wastefull. It might be even more if the list is using some tree concept with explicit pointers to related nodes. Due to the fact that we RAM is kinda expensive/limited and we want things to be scalable aswell, one should aim for minimal memory usage while still metting all query requirements.
So this is something I would decide from use case to use case.
However, using bitmasks allows for very fast bulk fitering of huge datasets. Let's say you store 2 bitmasks: 1 is loggedInToday, 1 is signedUpForNewsletter.
By using an bitoperation like AND (processors can do those operations really fast), you can suddenly filter out all user ids (represented by the bitposition's of the 1's) that have both logged in today and signed up for the newsletters. Because intersections of a bitmasks can be done by atleast one magnitude faster than those of two ordered lists of id's, you can suddenly do this operation on millions of users and still stay below 50ms.
To wrap up my answer: the usage of bitmasks allows for some realtime analytics that would otherwise not-be-realtime and can save you a lot of memory IF you are expecting many items in a list. Note that this is just one usage, there are many others (like bloom filters).