Sorry, I was just copy/pasting from the FAQ so you'd have more context (not the OP nor the developer of ZT). I don't know enough to know what the difference between "round structure" and "20 rounds of mixing"[1] is, but I'd love to find out. Are there better references than that wiki page?
They define a core transform, which nonlinearly combines key material with plaintext on a bit-by-bit basis and provides "confusion" and "diffusion".
You can think of modern cipher design as analogous to RISC computers. A designer has a choice: they can make a very strong transform function, or they can make a very simple transform which is weak by itself, but strong when repeated. The latter approach dominates modern cipher design.
Modern ciphers execute the transform (the "round function") many times. They take a key and expand it into subkeys, then use those subkeys with successive invocations of the round function, feeding the (gradually strengthening) ciphertext back through the cipher each time.
Curve25519 and ed25519 aren't ciphers. They are two different ways to use elliptic curve math in cryptography; the former implements Diffie Hellman key agreement in the mathematical domain of a specific secure curve, and the latter implements public key signatures in that same domain. Neither mechanism is suitable for encrypting data; they're used as tools to get two parties to agree to a cipher key to use to encrypt the actual data.
In TLS, for instance, Curve25519 might negotiate an ephemeral key between the server and the client (so that nothing would persist to disk that could be scooped up by NSA later and used to decrypt the session when it ends). Something like ed25519 could be used to sign the key exchange to make it impossible to MITM the session. The ephemeral key would get plugged into Salsa20, which would perform the actual encryption. It's Salsa20 that has the round structure.
Salsa20 wants 20 rounds, but the last 8 of those rounds are for extra security; the author believes it to be secure at 12 rounds, and nobody has disproved that, or has any reason to believe he's wrong. Salsa20 was designed for performance, and the cost of Salsa20 rounds is low, so 20 rounds was a pragmatic, cheap hardening mechanism.
On the other hand, the performance difference between reduced-round Salsa20 and real Salsa20 isn't significant, so that was indeed a goofy choice† on their part. Salsa20 is very, very fast. Not to mention: bulk crypto in general --- AES in CTR mode, for instance --- is also very fast.
I'm not sticking up for this particular project; just reacting to the idea that NaCL would need to be rekeyed frequently.
† (I'm taking it on faith that they actually are using Salsa20/12; I didn't look carefully.)
You can use Curve25519 as a cipher. It's just fairly slow, like all PKC. It's something like 600k cycles for 32 bytes, while AES is around 30 cycles for 8 bytes.
