Team CryptoInsightfull 
Hisotorically, the motivation was to allow spending of either the “local” or “remote” commitment anchors, without introducing further additional pin vectors. It had many short-comings, including lack of efficacy under adversarial conditions, and still costing substantial vbytes under even benign scenarios.
With respect to the variety of pinning vectors and their historical significance, I don’t think I’m going to do a lot better than BIP431 motivation section for TRUC transactions: https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki#motivation
In short, there are a number of pinning vectors that existed when the Lightning Network was first rolled out. “Full rbf” was not adopted across the network at the time. RBF fee pinning, package limit pinning, lack of package relay, lack of package RBF, and so on also existed, making replacements too expensive (and incentive incompatible) or outright impossible given certain conditions.
Since Bitcoin Core 28.0 much of this environment has changed: https://bitcoincore.org/en/releases/28.0/
With the planned update to “zero-fee commitment” channels (https://github.com/lightning/bolts/pull/1228), these problems are substantially reduced or eliminated, results in greater composibility, and results in smaller transactions in vbytes. There will likely be a single anchor output that is 0-value (or the trimmed HTLC amount), and PayToAnchor making it free to spend by either counter-party without a signature.
