The article on NaCl by its authors touches this subject. I'll quote here the relevant bit:
Nonces. The crypto_box API leaves nonce generation to the caller. This
is not meant to suggest that nonce generation is not part of the
cryptographer’s job; on the contrary, we believe that cryptographers
should take responsibility not just for nonces but also for other
security aspects of high-level network protocols. The exposure of
nonces simply reflects the fact that nonces are integrated into
high-level protocols in different ways.
It might seem simplest to
always generate a random 24-byte nonce n, and to transmit this nonce
as part of the authenticated ciphertext; 24-byte random strings have
negligible chance of colliding. If ciphertexts are long then one can
tolerate the costs of generating this randomness and of expanding each
ciphertext by 24 bytes. However, random nonces do nothing to stop the
simplest type of forgery, namely a replay. One standard strategy to
prevent replays is to include an increasing number in each packet and
to reject any packet whose number is not larger than the number in the
last verified packet; using these sequence numbers as nonces is
simpler than giving each packet a number and a random nonce. On the
other hand, choosing public nonces as sequence numbers means giving
away traffic information that would otherwise be somewhat more
expensive for an attacker to collect. Several different solutions
appear in the literature; constraints on nonce generation are often
tied directly to questions of the security and privacy that users
expect.
Current applications of NaCl, such as DNSCurve and CurveCP,
have different requirements regarding nonces, replays, forward
secrecy, and many other security issues at a higher level than the
crypto_box API. A nonceless API would require higher-level
complications in all of these applications, and would not simplify
their security analysis.