The important bit isn't the Maybe-types, but all types that are _not_ Maybe.
If types aren't non-nullable by default then any function parameter or return value can potentially be null and a robust program practically needs to have null checks _everywhere_. Otherwise, when your program throws a NullPointerException you'll have no way to know where that null originated from.
In Haskell, the types guarantee that you never ever have to check for null (in fact, you can't even) unless the function's type explicitly allows for the possibility of having a null. In addition, you have several ways to compose function calls that might return null in such a way that you don't have to check for each null case separately.
Finding out at what part of a monadic computation the return of a function put a None when there should have been a Some is much more tricky.
This is where Either comes in handy. Either allows you to attach extra information to the error condition (such as a String). This lets you have the same properties of Maybe but with more information when you need to disambiguate.
That's the theory. In practice, your code is clearer if you use Maybe's all along the composition path, otherwise you spend your time unboxing/lifting values.
If types aren't non-nullable by default then any function parameter or return value can potentially be null and a robust program practically needs to have null checks _everywhere_. Otherwise, when your program throws a NullPointerException you'll have no way to know where that null originated from.
In Haskell, the types guarantee that you never ever have to check for null (in fact, you can't even) unless the function's type explicitly allows for the possibility of having a null. In addition, you have several ways to compose function calls that might return null in such a way that you don't have to check for each null case separately.