The question is, why should this be part of the language or standard library? This can easily be achieved by a library.

The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not.

The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.

Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(

Non-nullable types aren't just about uninitialised vars, where did you get that idea? Consider that function parameters can also be nullable although you cannot help but initialise them. Nullable types (nonnull is the default) solve the issue of optionality: something that might be there sometimes but also may not be.

This is hard to explain and I didn't understand it either, after programming Java for 15 years. After 5 years of Scala I can't think of not using Option.

If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.

In Kotlin there's a bunch of null-handling operators, which allows you to really treat null as None. Like x?.y()?.z(). Moreover, you can define extension functions on nullable types, which covers Option's map and much more.