Why do multihop LN payments start settling from the recipient's end? In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash. 

What would be the problem if it had started with the sender? After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage, timelock set in increasing order across the path, contract initiated by sender having the least locktime. Receiver is the last node to settle the payment.



For reference, I am adding a picture so that one can visualize what I am trying to say.
I think you have answered your question yourself. If all nodes would behave honestly and in good faith your process would work. But in that case we would not need to go through the hustle of setting up htlcs to begin with but we could just forward money by changing the balances in each channel. The whole point of using htlcs is to make the payment process atomic and prevent nodes along the path from stealing funds.
Other than that I do not see any additional flaws.
Offtopic:
Looking at your recent post on the mailing list (c.f: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html ) I wonder if this idea of &quot;forwarding a second preimage&quot; in addition to the current process of &quot;releasing a preimage&quot; could be constructed to prevent griefing attacks because the sender could enforce settling the htlc in case someone stalls the process. But the way how I  imagine such a solution right now, it would basically run into the same problems as you already described in your initial question. It might be interesting to investigate if PTLCs (with adoptor signatures and payment decorellation) could be used to identify the griefing node and use such a process.