my team also prefers Option to Kotlin's nullable types. Option is much more clear and idiomatic FP than Kotlin's kind of not great implementation of nullable types.
Granted, Option.map and flatMap and nullable type ?.let{} are functionally equivalent but the former just reads so much better, and we want not just functor and monad but applicative as well, no?
Eg given a List<Option>, we can use applicative to declaratively and with referential transparency etc etc (you know the usual FP sales pitch) turn it into an empty list if it contains a single non-populated option, or a list of Foo if all options in the list are populated.
With Kotlin nullable types I don't think you could do it as declaratively and elegantly.
Actually, even if you could, it's kind of beside the point...
To me, the point is, Option has been designed from scratch to be an FP style Maybe type with all that comes with that in terms of it being a functor, applicative functor, monad etc etc whereas while Kotlin nullable types in some ways are functionally equivalent, a nullable type doesn't implement a Functor interface, or a Monad interface, or an Applicative interface, and when it behaves like it does, it's mostly kind of by accident driven by a pragmatic need, not any real understanding of reusable, lawful FP abstractions.
(from an old thread discussin this at
https://github.com/arrow-kt/arrow-core/issues/114)