It's not just about specifying more of the standard either. EdDSA is designed to be harder to screw up an implementation of, by construction.
While I not a FIPS certification expert by any means, it was intended that implementations could implement RFC6979 without breaking the standard by simply using a standard allowed DRBG in the right way.
> EdDSA is designed to be harder to screw up an implementation of, by construction.
That's the marketing claim at least. It's debatable. Some of its choices make it easier to screw up, and widespread implementations of it have also been wrong in the varrious ways it was intended to address. It's a good idea to try, at least, for sure.
I think nonce security in particular is not at all the best example since modern ECDSA implementations are secure against in that respect. I'm also aware of some systems which have had grave security flaws because they believed the EdDSA claim of a deterministic signature meant that it was a unique signature. The promotion of EdDSA itself as magic pixie dust creates vulnerabilities.
There is just no replacement for understanding. :)
One could just as well implement something EdDSA compatible with insecure nonce generation and people have done so (for years the thing you got when you goggled for eddsa python was just such an implementation).
It's good that the eddsa paper specifies more of the system, as people have made bad choices and ruined the security-- but even it fails to completely specify the system: the exact input handling isn't specified, which has resulted in security problems.