As of v160706, Comet Cache does not cache Nonce values (see What are WordPress nonces and why are they not cache-compatible?). However, after further discussion it was decided that Nonces could be cached safely, with a few caveats (see Caching Nonce values safely below). The decision to put in the work necessary to make caching Nonces possible came after lots of feedback from users frustrated that Comet Cache was not caching their pages due to a plugin/theme adding Nonce values to every page.

To improve the way Comet Cache handles WordPress Nonces, we need to do the following:

• Allow caching of Nonce values by default for Logged-In Users when Logged-In Users caching is enabled; a new option should be added to the Logged-In Users option panel to enable/disable this functionality if desired. Caching will remain disabled for users who are not logged in (as it is now).
• When Nonces are cached, the cache files that contain Nonces get an expiration time of 12 hours (other cache files get whatever expiration date is set in the Options). A new filter should not be added that allows a site owner to override this 12-hour cache file expiration, because as Jason put it, "anyone changing this will be going down the wrong path, without question [...] Exposing the filter suggests it's OK to do it, when it's not."
• A note should be added to the Comet Cache notes for that cache file indicating that a Nonce value was detected and hence the cache expiration time has been set to 12 hours (or whatever overridden value was set using the filter). A note is not necessary if the global expiration time was manually set to 12 hours or less.

Caching Nonce values safely

From what I've gathered, the only real way to cache Nonce values safely is to do the following:

1. Ensure that the cache file is being served to a user for whom the Nonce value was created (which means only Logged-In User caching in the context of Comet Cache). The only way Comet Cache can know that the cache file being served belongs to the visitor it's being served to is via Logged-In User caching.
2. Ensure that the user-specific cache files that contain Nonce values are not publicly accessible, otherwise attackers could find Nonce values in the cache files and attempt to exploit them. We need to take into consideration sites running Nginx (where .htaccess rules are not possible) and sites where we may be unable to write an .htaccess file to protect files in the cache from being publicly accessible. We may not need to worry about this; see more on this below.
3. Ensure the cache file that contains a Nonce value does not stay around for longer than the minimum lifetime of a WordPress Nonce, which is 12 hours. If it stays around for longer than 12 hours, then the user who loads the cache file will find themselves clicking buttons and submitting forms that result in an error due to the expired Nonce value.

Points 1 and 3 we can control: We can only Nonce caching only for Logged-In Users and we can set an expiration date on cache files that contain Nonce values to 12 hours. Point 2 is somewhat out of our control, however that may not be a problem.

@jaswsinc writes...

if we do decide to take this approach, we should be more and more careful about how secure the cache directory is. That's already something we consider, but when we knowingly cache a user-specific security token (e.g., Nonce) we must also assume responsibility for protecting it every way that we can; i.e., take some additional precautions.

The WordPress Codex says to "always assume Nonces can be compromised" and that "Nonces should never be relied on for authentication or authorization, access control." If we go by that, then we don't need to worry about making sure that cache files are not publicly accessible just because they may contain a Nonce value. (I agree, however, that we should still try to make sure user-specific cache files are not publicly accessible, as those will probably contain user-specific information that a site owner would not want to expose.)