Maybe and Either monads, shortcircuiting, and performance

Functional Programming in C++, at page 214, with reference to an expected<T,E> monad which is the same as Haskell's Either, reads

[...] as soon as any of the functions you're binding to returns an error, the execution will stop and return that error to the caller.

Then, in a caption just below, it reads

If you call mbind [equivalent to Haskell's >>=] on an expected that contains an error,, mbind won't even invoke the transformation function; it will just forward that error to the result.

which seems to "adjust" what was written earlier.

Indeed, my understanding, from Haskell, is that in a chain of monadic functions, all of the functions are called, as a monad carrying information about a failure is just one possible way of using a monad, as is the case for Maybe and Either, where the Nothing and Left constructors are forwarded untouched through the monadic bindings.

Still, in this specific two cases, I wonder if there's a performance penalty in doing something like this

justPlus1 = Just . (+1)
turnToNothing = const Nothing
Just 3 >>= turnToNothing >>= justPlus1 >>= justPlus1 >>= justPlus1 >>= justPlus1 >>= justPlus1

as in these cases the chain can't really do anything other than what it does, given that

Nothing >>= _ = Nothing
Left l >>= _ = Left l