If we should not reuse primes in DH, shouldn't we not reuse ECDH elliptic curve properties? An article How is NSA breaking so much crypto? describes NSA's methods for breaking encryption.


  If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number [...] an adversary can perform a single enormous computation to "crack" a particular prime, then easily break any individual connection that uses that prime.


Why do we generate these primes using tools like dhparam when using DH, but in ECDH we often admit which particular curve (like Curve25519) we're using?

Isn't that exactly what we should avoid? Shouldn't we generate the curve properties in a similiar manner? Or is that hypothetically correct but the computation is not even in well-paid adversary's capabilities?
The fact is that the discrete logarithm problem (DLP) is solved using different algorithms in the cases of multiplicative groups (where normal DH applies) and elliptic curves (where ECDH applies).

The behavior of these algorithms is quite different.

For multiplicative groups, where the NFS for logarithm is used, a huge part of the computation depends only on the multiplicative group itself and not on the single discrete logarithm.

See for example the logjam paper where in table 2 they mention the costs for sieving, linear algebra and descent (where descent is the only phase requiring the single logarithm as input, and therefore can't be precomputed).
For DH-1024 sieving and linear algebra requires 45 million core years while just 30 core days are needed for the descent. 
This means that after having done a huge precomputation, single logarithms are quite easy to extract.

For elliptic curve groups the situation is different. The best attack is Pollard's rho, which requires $\mathcal{O}(\sqrt{n})$ group additions for a group of size $n$. Now, computing in parallel $l$ discrete logarithm costs $\mathcal{O}(\sqrt{ln})$, which is speedup over the trivial $\mathcal{O}(l\sqrt{n})$, but not a significant one. In fact, the attacker is expected to compute $\mathcal{O}(\sqrt{n})$ additions before finding the first among them (see the "Batch Disscrete Logarithms" of the curve25519 paper.
Once the first discrete logarithm is found, the second one has still similar cost to the first one, not a much smaller one (like with the NFS).

Thus if $n$ is of reasonable size, it doesn't matter how $l$ is big as computing even the first logarithm will be out of reach.

Note: there are techniques that by using an extremely large precomputation effort allow to easily compute discrete logarithms. The important thing to understand the ineffectiveness of these approaches is that the precomputation effort costs significantly more than extracting a single logarithm (about $\sqrt[3]{n^2}$ additions which is greater than $\sqrt{n}$ for the single logarithm). 
See this paper for details.