Decompilation And Reverse Engineering

Program-Transformation.Org: The Program Transformation Wiki

The colloquial use of "reverse engineering" and the formal one are somewhat different. Crackers speak of "reversing" a program, when they are talking about a quick, focused exploration of an executable program, not the in-depth analysis (usually starting with source code) that is traditional reverse engineering.

Here is a diagram of the most traditional form of reverse engineering, architecture abstraction.
It was for a long time featured on the ReEngineering page, and comes originally from E. J. Byrne (A Conceptual Foundation for Software Re-Engineering, ICSM 1992, pp. 226-235):

I have my own diagram for the position of decompilation within traditional reverse engineering:

As you can see, decopilation stops where architecture abstraction starts (with the implementation, i.e. the source code).
Decompilation is certainly reverse engineering, since it is increasing the level of abstraction.
It's just that it starts lower and ends lower than most reverse engineering.
If a decompiler was used to recover old machine code into a new system, then decompilation would be part of this reengineering; the horseshoe would be a bit taller (at least on one side; usually compilation is not considered part of forward engineering, since it is a totally automatic step).