So, I'm not familiar with TypeScript...but I am familiar with other languages that use this mechanism (e.g., Scala) and there is a big difference between a "None" value (on an option type) and "null" value (on a reference).
Namely - you have to "unpack" an option type before you can access the value and the act unpacking (e.g., via pattern matching) forces the programmer to write the null check because the most natural way of accessing the data doesn't allow you to avoid it.
Now - that said - there are things like Option[T].get() (e.g., in Scala) which *will* unpack the value in an unsafe way. The distinction is still useful though - you generally shouldn't be using ".get()" and it's not the normal way of interacting with Option types.
This is opposed to the standard way of accessing nullable values (in, for instance, Java or C#) where the most natural approach to access a property or method on a reference requires you to first check for null.
Additionally - if you are writing a method in these languages which doesn't accept parameters of Option[T] but only accepts parameters of type T, then you can assume you are being given a non-null value because the expectations are very clear. Again, in C# or Java, there is no distinction here and null might very well be a valid value and there's nothing the compiler can do to help you find those types of mistakes.