Are instructions defined as expressions with side-effects?
The answer is no. But this is hardly enough.

I think you put your finger on a slightly sore but important point of
computer science and programming. We can pretty well define what is an
expression because that is well formalized in mathematics. But we
somehow wave our hands on what constitutes the essence of instructions, or
side-effects.  "Side-effect" is itself a strange word, with an almost
negative connotation, which says a lot about mixed feelings on the
issue. I do not mean that instructions have not been well formalized with
precise semantics (they have), but they often seem perceived more as a necessary
evil than as a desirable tool. And this is not easily explained. Maybe it is that, unlike expressions, they do not have an obvious counterpart in mathematics. There may be other issues.

But let's try to see the difference.

Mathematically, expression are precisely defined syntactic structures,
often called well formed formulae. From a computational point of view,
these expression are operateur operand structures, that are
interpreted in some domain of value (for operands) and of functions
(for operators). And an expression is just supposed to apply the
functions to the values in the order specified by the structure and
come back with the result (this is pretty close to the abstract
mathematical notion). As in mathematics, a function is supposed to be
just a mapping, giving a result in a given range.

I would define an instruction as a syntactic writing meant to specify
a modification in an environment. What then is an environment? An
environment is something that can be modified, and that can thus
memorize information (I should add transmit information, but let's
stay simple). A typical and very simple environment is the state of the finite
control of a Finite Automaton (FA). It can be changed, and the change
is memorized and can be used later on. A transition of a FA is an
instruction, since it changes the environment. In the case of a Turing
Machine the environment is constituted of the state of the finite control, the tape
content, and the position of the head on the tape. The content of the environment is precisely what is often called an instantaneous description of an automaton.

Since a side-effect is a modification of an environment, one
could say that an instruction is a syntactic structure meant to specify
a side-effect.

Note that the concept of environment (thus of side-effect) is itself
relative. It may be internalized so that we do not even have to know
it exists. For example, the evaluation of an expression may be done by
a device operating with a succession of instructions modifying a small
environment, until the end result is obtained. The modifications and the environment itself can
then be forgotten, and only the result is kept. There may have been
temporary "local" side-effects, but they are irrelevant outside the
evaluation of the expression. That is actually what happens in the
computer. But we still say that the evaluation of the expression has
no side-effect (none remains).

An environment can include places to store values (what is usually
called a variable). An instruction may be an assignment of a value in
some variable, and the value itself may be specified with an
expression. Conversely, the expression can include variables, and is
evaluated by replacing the variables by their current value in the
environment. So the two concepts interact, and are really two faces of
a computational coin.

Note in passing that we have considered that some environments are
more transient than others (for evaluating an expression). That means
that we may actually consider many environments. Managing environments
is actually a major issue in programming language design, and in
programming, particularly to make side-effects as transient as
possible to make program analysis and maintenance easier.

Coming back to our computational coin, the two faces appear in
various guises:  


denotational semantics vs operational semantics;
lambda-calculus,
combinatory logic or recursive funtion theory vs Turing Machines, automata and rewriting systems;
evaluation of expressions vs execution of instructions;
functional programming vs imperative programming;
regular expressions vs finite automata.


Sometimes, the same text can allows both readings. A context-free
grammar can be seen as a set equations between expression valued in
sets of strings (denotational view) or as a string rewriting system
(operational view).

Of course, in programming languages, things are made more complicated
by the mixing of expressions and instructions. Instructions use values
that are obtained by evaluation expressions. That is not too bad.
What is worse is that the evaluation of some expressions may cause
side-effects. This is because programming languages often allow
implementing functions with instructions as described above, but
without restricting the side-effects to a local environment that
disappear when the function terminate.

It may also happen that a function will not always return the same
result when called with the same arguments, because it uses internally
values provided by an outer environment that may be subjected to
side-effects. Though it is sometimes put to good use by programmers,
this may be a reason for the distrust of side-effects, as it seems to depart from our mathematical understanding of functions.