Scala's approach is sane because you can't dissalow nulls when you're working with libraries that work with null values. On the other hand Scala gives you the tools to deal with nulls very efficiently. You can easily lift nullable values to Options, and because Option is a monadic type, it can be used in for-comprehensions and is very composable.
That's a bit harsh. JetBrains and the developers of the compiler are certainly aware of the Maybe/Option approach, they chose not to use it. Their approach is not as composable as Haskell's but much more practical and more readable in my opinion.
If anything, the fact that Option is still used so rarely in Scala is an indication that maybe, that experiment has failed.
Just out of curiosity, how is Kotlin's approach less practical than Option? (I'm new to this style of programming) Is it because you can use Option types in maps and filters and the like?
Yes, but it goes deeper and I can't give it enough justice by typing this on my iPad.
The thing to understand about Nulls is that most often they denote non-fatal errors that have to be either explicitly handled or otherwise they get ignored. That's why nulls are evil, because NPEs take developers by surprise, at the worst possible time.
Monads are useful for dealing with errors. It's a tool, or a design pattern if you will, that makes the developer either deal with exceptional state or make it somebody else's problem. Developers that are not familiar with monads are doomed to implement it badly [1]
If you're interested for more and are a little familiar with Scala, I've attached an URL for an awesome explanation of this topic [2]
Languages like Kotlin are missing the point.