The conversation acknowledges that the primary justification for retaining ECDSA is tied to its application in legacy scripts, where entrenched systems would necessitate upgrades to facilitate any new signing operations if they were to move away from ECDSA, especially when considering Tapscript integration.

It has been highlighted that existing custody operations might prefer to stick with ECDSA due to trust in their current ECDSA Threshold Signature Scheme (TSS) and the desire to implement new protocols that incorporate features like post-signed vaults or delegation utilizing CheckSigFromStack (CSFSV). This preference arises from the resource implications of adopting an entirely new system. While they may have the capability to adopt new protocols, these operations may not have the bandwidth or willingness to audit newer signature schemes such as FROST (Flexible Round-Optimized Schnorr Threshold) or MuSig2 nor migrate to Tapscript for their applications.

Despite recognizing this stance, the sentiment expressed leans towards endorsing BIP340 Schnorr signatures exclusively for CSFS(V), leaving open the possibility of future upgrades allowing non-32-byte keys should there be a compelling reason to reconsider this position. The overall inclination suggests a trend toward simplifying the cryptographic landscape by focusing on Schnorr signatures, while remaining open to adjustments based on practical industry feedback and developments.