Would it make sense to add more types to the test? Like set, dict, tuple?

Will work with set, won't work with dict (because there's second type argument), will work with tuple (for unrelated reasons, though, () has a well-defined type tuple[()], context won't come into play here). I don't want to pin this dict behavior in test as it isn't ideal, we already have cases with empty tuple. Pushed a testcase with set to have Iterable vs Sequence difference captured by test, that's a good idea.

won't work with dict (because there's second type argument

But, __slots__ can be in a dict form:

>>> class A:
...     __slots__ = {'a': 'docs'}
...     
>>> A().a = 1
>>> A().b = 2
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    A().b = 2
    ^^^^^
AttributeError: 'A' object has no attribute 'b' and no __dict__ for setting new attributes

It can also be empty:

>>> class A:
...     __slots__ = {}

Shouldn't we support this case?

Yes, it's fine at runtime, we have tests for that, only empty dict will still produce "need type annotation".

Shouldn't we support this case?

IMO not. First of all, what's the type of __slots__ there? It's dict[str, ???], we do not have enough information to fill in the second argument. It's no worse than asking for type annotations on empty dicts elsewhere, is it? I don't think this use case is popular enough to add more special-casing down the road. However, I don't think it is important to raise "need type annotation" there, so do not want to add a test explicitly for this behavior.

ok, we can leave this for later :)