The "types as comments" proposal has a stated goal to not codify any semantics to the annotations.
This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.
If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!
That proposal is a practical joke. You haven't got a language at all if the words don't mean anything.