Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible.
Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
Expressing effects using monad transformer stacks might be more expressive and allow finer-grained distinctions, or whatever (please elaborate what you mean, I'm interested), but it's syntactically ugly (lift), it's confusing, and it's not clear that the expressiveness you get is practically useful.
In contrast, algebraic effects might 'only handle effects that trivially commute' (again, going to need more detail on this), but they're easy to understand and easy to use. They're much more likely to be a practically usable effect system that real programmers can really use in the real world in a way that doesn't convolute code with details of how you compose effects unduly.