The main selling point is that it helps reduce introspection spaghetti.

>>> import numpy.typing as npt
>>> def f(a: npt.ArrayLike, dtype: npt.DTypeLike) -> None: ...
... 
>>> help(f)

Before:

f(
    a: Union[collections.abc.Buffer, numpy._typing._array_like._SupportsArray[numpy.dtype[Any]], numpy._typing._nested_sequence._NestedSequence[numpy._typing._array_like._SupportsArray[numpy.dtype[Any]]], complex, bytes, str, numpy._typing._nested_sequence._NestedSequence[complex | bytes | str]],
    dtype: Union[type[Any], numpy.dtype[Any], numpy._typing._dtype_like._SupportsDType[numpy.dtype[Any]], tuple[Any, Any], list[Any], numpy._typing._dtype_like._DTypeDict, str, NoneType]
) -> None

After:

f(a: ArrayLike, dtype: DTypeLike) -> None

This can also help despaghettify type-checker output in some cases.

In case you're wondering about what those typing.TypeAliasType things are; they're what you get when you use the new Python 3.12+ PEP 695 type _ = ... syntax.
They're a bit different from typing.TypeAlias because they actually wrap the alias, which is accessible through its __value__ attribute. I don't expect this to compat issues though, since there's usually no reason to dissect these aliases at runtime.
Static type-checkers don't treat them any differently.