Algebraic effects and implicit arguments with explicit records are perfectly cromulent language features. GHC Haskell already has implicit arguments, and IIRC Scala uses them instead of a typeclass/trait system. The situation with extensible records in Haskell is more troublesome, but it’s more because of the endless bikeshedding of precisely how powerful they should be and because you can get almost all the way there with the existing type-system features except the ergonomics invariably suck.
It’s reasonable, I think, to want the dynamic scope but not the control-flow capabilities of monads, and in a language with mutability that might even be a better choice. (Then again, maybe not—SwiftUI is founded on Swift’s result builders, and those seem pretty much like monads by another name to me.) And I don’t think anybody likes writing the boilerplate you need to layer a dozen MonadReaders or -States on each other and then compose meaningful MonadMyLibraries out of them.
Finally, there’s the question of strong typing. You do want the whole thing to be strongly typed, but you don’t want the caller to write the entire dependency tree of the callee, or perhaps even to know it. Yet the caller may want to declare a type for itself. Allowing type signatures to be partly specified and partly inferred is not a common feature, and in general development seems to be backing away from large-scale type inference of this sort due to issues with compile errors. Not breaking ABI when the dependencies change (perhaps through default values of some sort) is a more difficult problem still.
(Note the last part can be repeated word for word for checked exceptions/typed errors. Those are also, as far as I’m aware, largely unsolved—and no, Rust doesn’t do much here except make the problem more apparent.)
Those who forget monads are doomed to reinvent dozens of limited single-purpose variants of them as language features.