I think one of the considerations that hasn't been brought up here is
accessibility for people who only occasionally write Python or people
who have to switch forth and back between languages (in our case
between Hack/Flow and Python). From that perspective there's a strong
case to be made for working towards syntax changes that other
languages seem to agree on rather than introducing yet more clunky
overhead.
It also makes the argument in favor of `T | None` for optionals more
difficult to make. Sure, it's short. But it's also difficult to
explain to anyone outside of our community why we're using the value
`None` to stand for the type of the value. It's impossible for people
new to the language to reason about this from first principles.
Using None is ubiquitous in typed Python code (e.g. any function that doesn't return anything has `-> None`) so this is just something people will have to get used to. I am strongly in favor of evolving usage to T | None instead of Optional[T] since it leverages two things commonly used in other ways (None and unions) without introducing any new syntax or semantics, and it avoids the confusion between different meanings of "optional" in English (and in Python, whether you're talking about function arguments or dict keys).
The syntax x? is quite controversial and unlikely to be accepted anytime soon (and requires parser changes so invites much more scrutiny). In TypeScript it has a special meaning, whereas T | null and T | undefined in TypeScript appears to mean similar things to T | None in Python (except for the endless shades of difference in meaning between null and undefined, and the fact that TypeScript, like JavaScript, always lets you leave out function parameters and keys, defaulting to undefined unless you look real careful).