From Minerva research team's web page[1]:
Update: The EdDSA scalar multiplication code in libgcrypt was leaking, however due to the way it was used, it was likely "not exploitable". It did not reduce the scalar which was a SHA512 digest by the curve order, but used the digest directly, thus the leakage did not represent the bit-length of the reduced scalar. Thanks to Daniel J. Bernstein for the note.
In other words, it was used in a way that djb never approved, so I don't think djb should be responsible for that. And it's not that the libgcrypt developers were stupid, but the due to how libgcrypt is architected, how bignum is implemented, issues on portability, legacy code, there were many difficulties to implement full constant-time code in libgcrypt.
In 2017, one developer said,
> dd9jn: Implementing constant time processing in a portable way is really hard up to impossible. DJB steps most problems aside by writing curve specific code for certain CPUs. We are in the process of improving our code for commonly used curves by replicating the reference code. Using the reference code directly is not possible due to different ways of representing big integers and the fact that the reference code has zero comments. For the Gnuk token (hardware OpenPGP card) Gniibe (author) is even considering to move to a different MCU to have better control over the pipeline.
In the article, djb had an analysis as well,
> The real fix, the constant-time approach, would start by changing the interface to replace mpi_get_nbits(k) with a maxscalarbits specified by the caller. But this would require going through dozens of functions that call _gcry_mpi_ec_mul_point and figuring out the appropriate maxscalarbits for each. This is an example of tension between simplicity and security.
> There have been many other timing-attack vulnerabilities in libgcrypt, and clearly there will be more. We have to throw away variable-time crypto code without waiting for attacks to be demonstrated. For example, libgcrypt should use the constant-time ladders supported by Curve25519. But this doesn't mean that Minerva broke libgcrypt's Ed25519 implementation: libgcrypt was saved by another Ed25519 feature, the double-size hash.
At least, maybe it would ease code review and introduction to cryptography.