Diff from mypy_primer, showing the effect of this PR on open source code:

pydantic (https://github.com/pydantic/pydantic)
- pydantic/v1/typing.py:47: error: Incompatible types in assignment (expression has type "tuple[()]", variable has type "type[GenericAlias]")  [assignment]
+ pydantic/v1/typing.py:47: error: Incompatible types in assignment (expression has type "tuple[()]", variable has type "type[GenericAlias[_OriginT_co]]")  [assignment]

discord.py (https://github.com/Rapptz/discord.py)
- discord/ext/commands/converter.py:1119: error: Return type "Greedy[T]" of "__class_getitem__" incompatible with return type "GenericAlias" in supertype "list"  [override]
+ discord/ext/commands/converter.py:1119: error: Return type "Greedy[T]" of "__class_getitem__" incompatible with return type "GenericAlias[type | TypeAliasType]" in supertype "list"  [override]

What problem does this solve? The class is not generic at runtime and I think pretending it is is likely to cause more confusion than it's worth.

What problem does this solve?

It makes it possible to annotate typing.get_origin:

Runtime-typing libraries that only accept subscripted types could also benefit from this: If e.g. x=list[int] is allowed but x=list isn't, they are now able to enforce this by annotating x: GenericAlias[list[Any]] (assuming static type-checker support). If I remember correctly, pydantic requires this is some places, raising a runtime error otherwise.

The class is not generic at runtime and I think pretending it is is likely to cause more confusion than it's worth.

I suppose that's a bit of a chicken/egg story. And in my experience, typeshed usually takes the lead in these kinds of things, and cpython then follows (e.g. #13760).
Also note that GenericAlias is likely only used by people with thorough knowledge about typing in Python. So I don't expect them to become confused by it being optionally generic.