It's useful if it's a monad (and functor) because then you have tools to avoid this check until the end of a series of possibly failing functions. It's only really useful with these tools though.
By itself you might as well use nulls or throw errors although you could argue that it's clearer having a maybe or an either.
> It's useful if it's a monad (and functor) because then you have tools to avoid this check until the end of a series of possibly failing functions.
The monad laws already fail miserably in Haskell when you account for nontermination. Haskellers can only cope with this by eschewing partial functions as a matter of coding style. Now, eschewing partial functions, not to mention effectful procedures, is essentially impossible in a unityped language like Python. Are you sure you still want to play the monad game?
Of course, the decision to tolerate leaky abstractions is very much subjective. But constantly dealing with abstraction leaks is, in my experience, far more burdensome than not using abstractions to begin with. This is especially the case with mathematical abstractions whose meaning is given by equational / rewriting rules.
By itself you might as well use nulls or throw errors although you could argue that it's clearer having a maybe or an either.