Hisotorically, the motivation was to permit spending of both the “native” or “distant” dedication anchors, with out introducing additional further pin vectors. It had many short-comings, together with lack of efficacy underneath adversarial situations, and nonetheless costing substantial vbytes underneath even benign eventualities.
With respect to the number of pinning vectors and their historic significance, I do not assume I’ll do lots higher than BIP431 motivation part for TRUC transactions: https://github.com/bitcoin/bips/blob/grasp/bip-0431.mediawiki#motivation
Briefly, there are a selection of pinning vectors that existed when the Lightning Community was first rolled out. “Full rbf” was not adopted throughout the community on the time. RBF payment pinning, package deal restrict pinning, lack of package deal relay, lack of package deal RBF, and so forth additionally existed, making replacements too costly (and incentive incompatible) or outright not possible given sure situations.
Since Bitcoin Core 28.0 a lot of this atmosphere has modified: https://bitcoincore.org/en/releases/28.0/
With the deliberate replace to “zero-fee dedication” channels (https://github.com/lightning/bolts/pull/1228), these issues are considerably lowered or eradicated, ends in higher composibility, and ends in smaller transactions in vbytes. There’ll doubtless be a single anchor output that’s 0-value (or the trimmed HTLC quantity), and PayToAnchor making it free to spend by both counter-party with out a signature.
