There's a previous discussion about this somewhere (it's from earlier this year, written for a NIST summit on next-generation elliptic curve standards).

I can offer a quick cheat sheet:

* The NIST ECC problem everyone is aware of is that the seeds used to generate the curves have totally unknown provenance. Pretty much everyone agrees that's a problem; it's not really a live issue. Whatever the next curve standard is, it won't have this problem.

* NIST's ECC standards included an ECC-based PKRNG, which is a CSPRNG based around a public key operation rather than a hash or cipher. Pretty much everyone agrees that the only practical reason to use a PKRNG is to allow the holder of the secret private key to extract the state from people's RNGs and predict their random numbers; it's a form of key escrow. It was very bad that NIST standardized a PKRNG.

The meat of the paper is about Curve25519 and Ed25519, Bernstein's competing curves. These constructions are basically responses to the flaws of the NIST standards:

* The NIST curves are misuse-prone. When receiving ECC parameters from your counterparty, there's a validation routine you must perform precisely, or else an attacker can trick you into performing a computation using your secret on an unexpected and insecure curve. This attack is very simple to perform and pretty spectacular: you can use it to remotely suck the private key out of a remote server. There are some variants of the attack (oversimplifying: there's the generic problem of not doing validation, and the more sophisticated problem of how you send coordinates, and whether protocol details like this can allow attackers to force attacks onto related-but-insecure "twist" curves).

* The NIST curves are difficult to implement without timing leaks. That's what the Montgomery Ladder stuff is about: it's an algorithm that's simultaneously constant-time, efficient, and simple. NIST's curves are difficult to work with in these terms, and Bernstein's aren't.

* The NIST curves have a naive design with respect to modern computer architecture, and so it's easier to generate fast curve software with other curves (like Curve25519; the 25519 refers to the structure of the prime field it works in, and that prime field was chosen to be efficient to compute on in software).

* NIST originated DSA and ECDSA, the two most popular public key signature protocols. DSA/ECDSA sucks. A lot. They rely on random nonces and blow up spectacularly if those nonces are biased; it's become a bit of a sport in ECC research to get practical attacks out of extremely small nonce biases (a problem that's easy to have).

* Modern signature schemes have a bunch of nice features that DSA signatures don't; they're bulletproofed internally against attacks that could isolate weaknesses in specific parameters (the hash used, the nonce and the key), the math is tweaked so that things like modular divisions that are hard to do in constant time are replaced with multiplications, and the system is hardened to make it difficult to launch batch attacks (attacks where it costs only marginally more to attack 1000 signatures than to just attack 1). The next NIST signature standard should be like those nice signature systems, not DSA, which, again, sucks.

The paper is worth reading! I think it's a little easier to read with the roadmap. :)