Curve25519 is designed to be resistant to timing attacks, such as clamping the 254th bit in x25519 keys to 1 so that implementors can not optimize away a multiplication round.
That doesn't mean that this implementation doesn't have timing attacks, but the implementors claim they chose mechanisms which should be constant-time.
> Does 25519 suffer from key/data-dependant execution time?
I mean, when implemented naively, yes, but the industry has been aware of timing attacks for decades such that this is table stakes for any crypto implementations.
From the article:
> We also do our best to execute the algorithms in constant time, to thwart side-channel attacks that infer secret information from the durations of computations.
https://github.com/awslabs/s2n-bignum (where most of the heavy lifting is done, per the article) further explicitly states that "Each function is moreover written in a constant-time style to avoid timing side-channels."
The next paragraph makes a slightly stronger statement about its constant-time'ness:
> Our implementations of x/Ed25519 are designed with constant time in mind. They perform exactly the same sequence of basic CPU instructions regardless of the input values, and they avoid any CPU instructions that might have data-dependent timing.
[Widely used] Cryptographic Rust crates offering "constant time" operations in "pure Rust" — but Rust has no primitives for doing constant time operations, so it's only through hopes and prayers that it might actually work, and with no guarantee anywhere that it actually should.
(Other, less timing attack related stuff, but e.g., major companies still not supporting anything beyond RSA.)
That doesn't mean that this implementation doesn't have timing attacks, but the implementors claim they chose mechanisms which should be constant-time.