With some disclaimers that it's been a while since I've done this and also probably you should verify crypto advice you get from a web forum anyway:

Reusing the same nonce and key to encrypt two different messages is very, very bad: in most schemes it leaks a lot of information about the plaintext and/or the key immediately. One easy conceptual example is CTR mode (or any of the authenticated-encryption modes based on CTR), which uses the key and nonce to generate a stream of bits that are then XOR'd with the plaintext. If you encrypt two plaintexts with the same stream, an attacker can XOR them together and the encryption cancels out, which basically reduces the attacker's problem to just the sort of cryptanalysis that was popular in the pre-computer era. (This is the exact same problem with using a one-time pad twice.)

Reusing the same nonce and key to encrypt the same message is only bad in the sense that you'll get the same ciphertext. Most good cryptographic systems attempt to avoid leaking even the bit of information that two ciphertexts exhibit the same plaintext, and using unique nonces (or random nonces from a large-enough space of possible nonces) gets you that. SIV and therefore Miscreant leaks this information, but remains secure if you're encrypting two different messages. For some protocols, leaking information about a message being repeated is bad - imagine an online poker game, where the message is what card your opponent has. If you see the same ciphertext twice, probably that gives you a significant advantage. For some protocols, possibly including the distributed reconciliation you're talking about, maybe that's totally fine.

Also, SIV (and therefore Miscreant) is quite a bit slower than other schemes, because it processes the message to compute the nonce and then again to encrypt the message now that it knows how to do that. For some protocols this is a big tradeoff. Since you mention "distributed filesystem" and "bitcoiny," I'll guess that's not a problem for you, but also given those constraints, probably just using a random IV selected from a large space is easy to do, so you might as well do that. Maybe do that and also use SIV, if you don't trust your users' offline RNGs.

Since you mention content-addressed filesystems, take a look at the message-locked encryption construction, which is at a high level just SIV taken to an extreme: instead of just deriving the IV, you also derive the key from the hash of the message. This is a good primitive for building cross-user deduplication for something like an end-to-end encrypted version of Dropbox, because two unrelated users who happen to have the same file will produce the same ciphertext, while (at least in theory) if you were never in possession of the cleartext, you have no way to compute the key that was used to encrypt the ciphertext. However, it's got some inherent tradeoffs just by the nature of the problem, so if you don't need dedup across mutually untrusted users, don't use it. If you do, and you want your files to be content-addressed across users, MLE will make sure different users get the same ciphertexts and therefore the same hashes of ciphertexts for the same input files.