The Rust example is illustrative, and indeed I was thinking about it when I wrote my post. One valid angle is to say that languages should hide the reality of the machine from the user any time it would get in the way of the pure semantic description. Another angle though is to say that actually these concerns are important, and if the result is that the idealised abstractions aren't sufficient to capture them, then it's correct to put away the abstraction. It's not like ‘simple and easy to learn’ is a function of this elegance either; Haskell is hard to learn and Go is easy, so clearly there's something else to it.

You also mention list comprehensions forming a monad. I think this is also a good illustration of the difference. In Haskell the structure of a type tells you the dependency tree of a computation, so it's not a problem that Monad maps the type to itself. Your list monad is just a bunch of thunks pointing to each other either way. In imperative languages, types describe what has been reified and how it's organised in memory. In these, a list monad is an actively bad abstraction; you almost always want to distinguish the stateful computational pipeline (eg. an iterator) from the source and target storage (eg. an array). Neither of those are monadic for good reason.