Rationale for verification with cofactor $2^c$ in EdDSA? In EdDSA for more curves, it's described two options of signature verification

Verification, which checks $2^c\,S\,B\,=\,2^c\,R+2^c\,H(\underline R,\underline A,M)\,A$
Cofactorless verification, which checks $S\,B\,=\,R+H(\underline R,\underline A,M)\,A$

Cofactorless verification is more stringent: &quot;any alleged signature that passes cofactorless verification will also pass verification&quot;, but &quot;a signer using a secret key outside the normal signing procedure can create strings that pass verification without passing cofactorless verification&quot;.
So, what's the rationale for the first kind of verification, with cofactor $2^c$? If somewhat it's faster/simpler, why?

Update: after looking at this answer and it's references, I wonder if the only reason Verification¹ is defined is so that it holds the following
Proposition: If a set of signatures passed batch verification, then each signature passes Verification¹ with cryptographic certainty (including if signers are intentionally messing up or if adversaries modify signatures).
Is this proposition true? What's a proof? Why would not it hold if Verification was defined as Cofactorless verification?
Is there any other reason for Verification with cofactor? Like, a Fast Single-Signature Verification as in section 5 of Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang, High-Speed High-Security Signatures, in proceedings of CHES 2011)?

¹ Verification as defined above, that is with cofactor $2^c$.
It's flawed to imagine that &quot;more stringent&quot; is somehow stronger.  Actually ed25519-dalek's verify_strict method makes this mistake.
There are many plausible verification methods, which all define valid signature schemes based upon the same ed25519 keypairs.  You'll find them described in https://eprint.iacr.org/2020/1244 and https://hdevalence.ca/blog/2020-10-04-its-25519am
Almost none of those schemes agree perfectly with batched ed25519 signature verification however because batch verification randomly cancels out some cofactor tweaks.
If you employ ed25519 in a consensus protocol, like for accounts on a blockchain, then you'll want batched ed25519 verification that agrees perfectly with single ed25519 verification.  In such cases, you should use ZCash's ed25519 crate ed25519-zebra.  Afaik, all other ed25519 implementations exhibit variations between batched and single verification (as of march 2021).
I doubt TLS would adopt cofactor clearing verification, in part because cofactor-less verification runs slightly faster than cofactor clearing verification.  In fact, TLS could already batch verify ed25519 because one never has third parties check TLS handshakes in consensus protocols.  I suppose a CA could issue a certificate that worked only intermittently and only on some clients.