Addressing the core of your question, instructions are typically stored in a format that requires some translation (decoding) to become the control signals for instruction execution. Requiring some decoding presents an abstraction layer between the hardware and the software, allowing the control signals used for execution to be changed without breaking binary compatibility.
The instruction format exposed to software is also typically denser than the final control signals used to control execution. Typically not all possible combinations of control signals will be generated by valid instructions. For example, a very simple twos-complement adder supporting addition, subtraction, and addition with carry might have two control signals — one controlling whether one operand is inverted and the carry-in value is set to one, the other controlling whether the carry-in value is used. Both signals would be asserted for subtraction, neither for regular addition, and the second signal only for addition with carry. Asserting only the first signal would produce A plus one minus B, which is not a commonly useful operation.
In addition, naming a pipeline stage Decode is a conventional simplification. With a conventional RISC instruction encoding it is relatively easy to calculate the target of a PC-relative branch during decode because the immediate offset is a fixed field in the instruction and the PC is available. (Even if it is not known that the instruction is a taken branch early enough to allow enough time for the addition, the addition can be performed speculatively and the result ignored if the instruction is not a taken branch.) It may also be possible to evaluate branch conditions during this pipeline stage (the five-stage MIPS R2000 pipeline did this to only require a single branch delay slot to keep the pipeline full).
With a direct-mapped or way-predicted cache, the tag check can also be done in parallel with decode itself. (A cache miss or way misprediction would require the instruction to effectively be converted into a nop, but supporting modestly greater instruction cache latency might allow tradeoffs in the cache design.)
The Decode pipeline stage can also be used to detect various data and structural hazards relative to previous instructions and take mitigating actions (e.g., using result forwarding) or restraining actions (e.g., stalling the pipeline).
In a simple RISC pipeline, this stage also typically includes the reading of register operands (fixed register name positions make this independent of decode; this may involve unnecessary reads when the instruction only has one register operand but excess reads do not effect correctness). (In fact, for the 8-stage MIPS R4400 pipeline, the stage which decodes the instruction is named "Register Fetch". This stage decodes the instruction, detects interlock conditions, confirms a cache hit, and fetches register operands.)
(Such parallelism in instruction processing is not the only way that processing done during a pipeline stage may not be limited to the activity for which it is named. The division the sequential activities into pipeline stages does not have to map exactly to common conceptual divisions. For example, some of the latency of instruction cache access might be moved into the Decode stage (such that actual decoding cannot begin until some time into that stage). Similarly, some of the work associated with execution (e.g., the inversion of an operand for subtraction or the shifting of an operand by a small constant) might be hoisted into the Decode stage.)
Some processors store partially decoded instructions in the instruction cache. This can reduce the time (and potentially energy) required in the later decode at the cost of additional bits in the cache. Recent high-performance Intel and AMD x86 processors include a µop cache which stores essentially fully decoded operations, saving both time and energy and facilitating the providing of more µops per cycle.