"Effect" is a more general idea. It's a lens for viewing any kind of impure computation[0]. Monads are a model for effects. You can view them as pure[1] computation in lambda calculus or as defining a region of code which, internally, has impure effects.

So to summarize: effects are a general concept, monads are a particular technology for implementing that concept.

Further complexity ensues when people start talking about the general concept of a monad which is interesting in its own right but it has a more sophisticated relationship with the concept of effects.

[0] Purity is a property of, say, functions. Its definition is a function `f` is pure if and only if

    const () . f = const ()

which usually means that non-termination is impure as well. The notion of equality you use above can finesse this definition a lot.

[1] As stated in [0], non-termination is an effect, so Haskell monads are impure in that sense. Haskell typically ignores non-termination effects, though. Generally, monads would work more or less just fine even without non-termination though. Externally you can think of them as pure.

Ironically, I added that just as I was linking it here, despite the date on that post.

In addition to tel's discussion, what I was really trying to get at is that monads aren't "about" IO effects in particular, they're not about "impurity". In this case the whole thing is pure.

Defining effects at a deep programming language research level can bring a different understanding, where all monads are about effects, but "effects" has a different meaning that most people understand.

I'll ponder how to clarify that better.

My suggestion is to use "side effects" -- it seems to me that most people have an intuitive understanding of that term.

... but I may be wrong about that.