Because it would create a nasty dependency of the CLTV deltas over the CSV delay or a reduced security for HTLCs.
Having the revocation path in the second-stage transaction allows to be able to timeout an HTLC (ie your peer cannot redeem it via pre-image anymore) while still leaving the revocation period (CSV) intact for you to be punished if you cheated.
The Lightning Network protocol makes use of two-stage HTLCs.
Why: allow to use absolute timelock delta shorter than the relative timelock delta used for the fundamental security model (punishment), without degrading the security model for HTLC outputs.
How: make (basically) HTLC outputs pay to either the revocation path, the [timeout/success] transactions only broadcastable after block
B, or the receiver with the preimage. Make the [timeout/success] transaction pay only after full expiration of the revocation period (no preimage path anymore here, if the receiver did not cheat they will get paid).
More about two stages HTLCs in this answer.
Why put the revocation path at both stages ?
Because the first stage expires at the end of the absolute timelock period, which is likely to be less than the revocation period.
If the revocation path was not present in the second transaction (which is actually the point of using two stages) then you would either drastically reduce the revocation period for HTLC outputs, or require using insanely high CLTV deltas.
I've a channel with you, and we agreed on a
to_self_delay of 144 blocks (1 day to punish the broadcast of a revoked state) and a (reckless)
cltv_expiry_delta of 6 blocks.
I just attempted to make a payment through our channel. We appended an offered HTLC output to my commitment transaction and a received HTLC output to yours.
Let's say someone found funny to not take its negligible fees and instead stuck the HTLC to mess with us. After 4 blocks, we fail the HTLC, sign a new pair of commitment transactions and continue operations --I'll lean later on that you actually stuck the HTLC just after gathering the preimage.
We don't create new states to our channel and the same night I suffer a power outage, my node comes offline and I don't notice it until I'm awake (5 hours later).
At the exact moment I got offline you took the absolutely irrational decision to broadcast your ancient commitment transaction in which you still have a signed received HTLC output.
Your transaction gets confirmed, and passed the 6 blocks (still 4 hours until I wake up) you can claim the output with your HTLC success transactions.
4 hours later, I wake up, put my continuously backed up node back online and notice the breach.
Before I could even have the time to feel disillusioned, disappointed and frustrated enough to throw swear words to a random internet colored alias, my node can stealed your coins from your commitment transaction's
to_self output, claim my
to_remote output and spend your HTLC success transaction.
Without the revocation path in the second stage my coins would be lost.