A common operational definition of side effect is that it's an aspect of the behavior of a program that depends on when you execute it. A program that is effect-free always has the same behavior no matter when you execute it.
This is most useful when you consider subprograms. If subprograms A and B are effect-free, you can execute A before B, or B before A, or A and B in parallel: the behavior of the overall program will be the same. If subprogram A is effect-free, you can execute A a different number of times, which is something optimizers often do.
In particular, if A is effect-free, and the overall program happens not to depend on the value of A, then A does not need to be executed at all. In other words, effect-free subprograms can be optimized away. Programs that have side effects usually cannot be optimized away.
Going by this definition, divergence (i.e. non-termination) is a side effect. Suppose that subprogram A has no external side effect (e.g. consuming input, displaying output, or modifying the content of a memory location that is also used by some other part of the program) but does not terminate. And suppose that the overall program does not use the value of A, and terminates if you don't evaluate A. Then removing the evaluation of A does make a difference to the program's behavior: it goes from not terminating, to terminating. This wouldn't happen if A was not effect-free.
There are other possible definitions of side effects. Typically, anything that is part of the semantics of an expression and that isn't the expression's type or value is considered a side effect. This includes modifying a memory store, interacting with external entities (input/output), etc. Going by this definition, a subprogram whose value is not used can be replaced by another subprogram which has a different value, but the same side effects.
With denotational or big-step semantics, the non-termination of a program is apparent in the semantics and you can't simply replace a terminating subprogram by a non-terminating program or vice versa. But with small-step semantics, the non-termination of a program is not directly apparent in the semantics. So it's possible to replace a terminating subprogram by a non-terminating program or vice versa without changing the possible reduction steps apart from reduction inside the subprogram.
In the usual semantics of the lambda calculus, the usual semantics is a small-step semantics (beta-reduction), where the only thing that matters is what a term reduces to. There is no store, no I/O, or anything else that looks like a side effect. Therefore most semanticists say that the lambda-calculus has no side effect — there are no side effects according to the definitional definition of ”side effect“.
However, the lambda calculus does have a side effect in the operational sense that I described above: if you replace a non-terminating term by a terminating one, you get a term with a different semantics, since its set of possible reductions (its Böhm tree) has a different shape. For example, $M = (\lambda x. y) \Omega$ and $N = (\lambda x. y) z$ have different Böhm trees, since $M \to_\beta M$ but $N$ only reduces to $z$. Even though the value of the argument of $(\lambda x. y)$ is not used, its termination matters, so its termination is a side effect in this sense.
Non-termination is often used to characterize the equivalence of terms because it's a way to observe the behavior of a program without looking at the program itself. There are many useful equivalence relation on programs. Some of these equivalences are directly based on the evaluation rules of the program. For example beta-equivalence is defined by the existence of a chain of beta-reductions (each reduction in either direction) between two terms. But why should we think that this is a useful characterization of lambda terms? For example, all lambda terms (in the pure lambda calculus) are functions. Is it true that if two lambda terms are beta-equivalent, then applying them to the same argument yields beta-equivalent terms? Yes (trivially). Is the converse true? No: you need to add eta-conversion. Is this enough? Yes (in a sense that I won't go into). How can you tell what an equivalence does other than by describing it in terms of its definition? By looking at whether terms diverge. A divergent term is definitely different from a non-divergent term. A term that causes a context to diverge (a context is a program with one hole in it) is definitely different from another term that causes the same context not to diverge.
In the simply typed lambda calculus, all terms converge: the simply typed lambda calculus is strongly normalizing. (So are many typed lambda calculi, because typed lambda calculi are often defined for use in logic and non-termination is pretty much anathema to logic because it translates to being able to prove anything.) So simply typed lambda terms are effect-free even by the more restrictive definition.