Well, yes, that's the point. You don't need to understand anything about monads to understand how the implementation of >>= for IO forces the correct order of side effects.
But I do agree with the general idea that Haskell as a language is still a leaky abstraction, you still need to understand a lot of behind-the-scenes stuff, like how the RTS interacts with the OS ABI, how concurrency is implemented, the consequences of laziness and so on. Just knowing the denotational semantics of the language is not enough.
No, there is nothing in the type of >>= which guarantees sequencing of side effects. So for example:
a >>= (\b -> c)
There is nothing in the type of >>= that guarantees that a will be completely evaluated before c is evaluated.
I suspect this misconception is what makes many people think that Haskell's way of handling IO has something crucially to do with monads.
Well, that's in theory at least. In GHC Haskell the ordering is not denoted by neither data dependency ot the operator semantics, but by a complex set of rules that change from one version of the compiler to the other.
1 - Although it is sufficient for any monad that lacks real-world effects.
2 - Well, technically nothing is enough for really ordering IO operations, but those two properties give single-threaded semantics to IO.
Saying that lists are an instance of Monad in Haskell says much more about novel ways you can use a list in Haskell than about properties of a monad.