One reason to use HTLCs for single-hop payments in the Lightning Network would be to make them indistinguishable from multi-hop payments to the receiver. This way, the receiver does not know whether it was their direct peer who initiated the payment, or whether they are merely forwarding the payment on for somebody else. Since they look identical to the receiver, the receiver must assume that some other node, who they know nothing about, initiated it.
The way in which HTLCs are created is also useful even for the single-hop use case, because they extend the RSMC model with conditional payments. With RSMCs alone, if Alice wishes to pay Bob, she creates a new commitment transaction by reducing the channel balance paid to her, and increasing the balance paid to Bob via the RSMC output. This transaction is then signed by Alice. Assuming that nobody misbehaves, Alice has effectively already paid Bob. There is no way this payment can be undone by Alice - for example, if Bob fails to deliver a service which was expected for the payment.
In the HTLC case, the payment is conditional on Bob surrendering a secret which is the pre-image of a previous agreed upon hash. Alice signs the HTLC with the condition built in - in such a way that it is revocable by Alice after a time-out if Bob fails to deliver the keys. The rest of the balance of the channel beside the amount paid in the HTLC is unaffected by this payment and behaves as in the single-hop case.
These conditional payments have several advantages. They can be used in things such as atomic swaps and submarine swaps - where the receiving of a pre-image is sufficient to claim a balance of goods elsewhere (another cryptocurrency for example). There are probably many use cases which aren't even explored yet.