The BIP340 SchrorrSig standard states that during the signature there is a verification step, aborting the signature if verification fails. It is not mandatory, "it is recommended, but can be omitted if the computation cost is prohibitive".

The underlying secp256k1 library is written in C and ASM is very very efficient on multiple platforms. I can't see so much case where this cost is prohibitive. The only cases I can see is on small connected devices, embedded systems, or security chips, which are running below 50 Mhz, without full crypto-accelerator. Also this library is the central security implementation in Bitcoin and many other blockchains, and it should should enforce best security practices. Plus the embedded small platforms would be the most vulnerable about the provoked computation errors to leak the private keys. But it is not an issue if the small devices has only a small amount in its private key.

The reference implementation in Python is performing this verification step, in accordance with the standard.

The libsecp256k1 library code documentation used here explains that the secp256k1_schnorrsig_sign method "does not strictly follow BIP-340 because it does not verify the resulting signature. Instead, you can manually use secp256k1_schnorrsig_verify and abort if it fails." So this is up to the secp256k1 library users, here the Bitcoin developers, to add the verification of the signature.

I propose the following change :

Adding the verification step in src/key.cpp CKey::SignSchnorr method.
And make this optional with compilation flags, by default activated, and users of this consensus software can choose to disengage this security intentionally if they feel that can hurt the computation time over security when signing. For example a leaf key making hundred thousands small transactions a day, with small amount in the address balance, in a small slow embedding device.

At the very least, one should add a comment note in the SignSchnorr code (or header), explaining and justifying how the computation cost is prohibitive, so the verification step is omitted. For now the comment says SignSchnorr "create a BIP-340 Schnorr signature" and that builds an incorrect feeling of security like as it would follow the given standard.

An other way, can be to amend the standard, to relax the recommendation, and it could state the verification step is only a possibility to zealous user for stronger security.

From the security point of view, the verification step has to be added. We just need to discuss users experiences and usage of this software, if the removal of this security protection is a benefit for most users. And especially, from the standard statement, justify that the computation cost is prohibitive, so this security step can be omitted like it is now. The standard makes the choice to strengthen the security against some kind of attacks, and states this can be disabled if this security measure uses prohibitive resources in practice. The standard doesn't say this is an extra feature up to the implementation choice. Actually, this is recommended, but there are specific conditions covering the reasons when it can be omitted.

The optimizations to reduce the computation resources is focused on signatures checks, and should not be a matter over security for the signing process.