> There's actually a counter example on that Wiki page - the highly complex numbers used in the NIST curves, for which no path to derivation was publicly provided.

It's both. The security of curves are evaluated according a set of criteria:

1. Whether the cost for attackers by the Rho Method is above 2^100? (security margin against known attack)

   - NIST P-Curves: Yes.

   - Curve25519/448: Yes.

2. Whether the curve has resistance against additive and multiplicative transfer to avoid potential attacks via index calculus? (security margin against known attack)

   - NIST P-Curves: Yes.

   - Curve25519/448: Yes.

3. Whether the absolute value of this complex-multiplication field discriminant D of the curve is larger than 2^100 to avoid attackers from benefiting from possible speedups to the Rho Method? (security margin against known attack)

   - NIST P-Curves: Yes.

   - Curve25519/448: Yes.

Notably,

   - Bitcoin Curve (secp256k1): No.

But it doesn't mean Bitcoin is broken, it just decreases our confidence that it would be still secure if HUGE speedups to the Rho Method are found for a practical attack. But finding it seems unlikely.

4. Whether the coefficients of the curve are justified mathematically? (security criteria against backdoor)

   - NIST P-Curves: No (!)

   - Curve25519/448: Yes.

   - Bitcoin Curve (secp256k1): Okay.

For example, coefficients for NIST P-256 (secp256r1, prime256v1) is generated by hashing random seed:

    c49d3608 86e70493 6a6678e1 139d26b7 819f7e90

Nobody knows what is it. NIST has its own defense: this random seed is only used as the input of SHA-256, since all cryptographers know that SHA-256 is secure, nobody, not even the NSA, can invert SHA-256, the output must be secure. They called it "verifiable randomness". But it's still room of doubts for sophisticated cryptographers, e.g. See this highly-amusing, satirical paper with lots of insight on this issue: How to manipulate curve standards: a white paper for the black hat https://bada55.cr.yp.to/bada55-20150927.pdf

Coefficients for secp256k1 are not fully explained, but nothing fishy and generally looks good.

And keep in mind that when Satoshi Nakamoto was developing Bitcoin, secp256k1 was the best choice among available, well-accepted standard curves from this perspective, obviously, Satoshi must be an experienced hacker and have made a careful decision.

5. Whether the construction of the curve allows "simple" multiplication and addition. (security criteria against implementation pitfalls).

   - NIST P-Curves: No.

   - Curve25519/448: Yes.

   - Bitcoin Curve (secp256k1): No.

Curve25519 utilizes a mathematical technique called Montgomery Ladder, which also allowed the practical implementation of constant-time, side-channel resistance crypto. On the other hand, NIST curves make it difficult.

6. Whether the curve still offers strong security guarantee even if an attacker has "twisted" the curve, e.g. fooling a program to choose a point which is not on the actual curve. (security margin against known attack and implementation pitfalls)

   - NIST P-Curves: Yes.

   - Curve25519/448: Yes.

   - Bitcoin Curve (secp256k1): Yes.

7. Whether the representation of curve points are indistinguishable from uniform random strings. (security usefulness in various protocols)

   - NIST P-Curves: No.

   - Curve25519/448: Yes.

   - Bitcoin Curve (secp256k1): No.

Therefore, we conclude Curve25519/448 is more robust than NIST curves.