Case of RREP: When nodes receive RREQ (Route request) for a destination node, then two types of nodes can respond to it. One is the destination node itself -- in this case, it can increase the seqeunce ID. The second types of nodes are those that have an existing route to the destination node. Now, they have already saved the seq number that was generated by the destination node, when they received the route. When sending a RREP, these intermediate nodes simply copy the earlier learnt sequence number (and do not generate a new one). This way, if the destination were to send a new route, then the node that generated RREQ, when it receives the RREP, it can pick the one with the latest sequence number and ignore the ones that are stale.
Here is what the RFC says about the destination node sending RREP:
If the generating node is the destination itself, it MUST increment its own sequence number by one if the sequence number in the RREQ packet is equal to that incremented value.
Case of RREQ: Nodes also maintain reverse routes (let us say, for node X) and they would want to update the route to originator of RREQ (node X) only when they receive a new RREQ from node X. One way to do this is to let X increment the sequence number whenever it sends a RREQ.
A note on destination sequence number field in the RREQ: As per section 5.1, when originating RREQ: "Destination Sequence Number: The latest sequence number received in the past by the originator for any route towards the destination.". As per section 6.5, when processing RREQ: "Lastly, the Destination Sequene number for the requested dest is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the requested destination."
So, basically, settting/updating Dest Seq Number means that the sender or forwarder of RREQ is indicating that I have the information till, let us say seq 101, that was sent by the destination node. If that is not the latest, then the destination node does not bother to increase its own sequence number before sending the RREP (section 6.6.1).