Absolutely. Data at rest will presumably eventually be used for something, and you don't want that use being influenced by an attacker. Most attacks on data integrity are the sort of thing that work best if the attacker knows at least the structure of the plaintext and ideally some of the content (which is easy with HTTPS, for example, but possible with many file types that use known offsets or similar).
The ease of such attacks depends on a lot of factors. Do you (the attacker) have write access to the ciphertext at all? Did the adversary use something like a stream cipher (trivial to flip bits in; each change in the ciphertext directly corresponds to a change in the plaintext with no side effects) or a block cipher where, even if you successfully can flip the bits you care about, you'll probably scramble other parts of the file? Can you make your desired change without editing the length of the data (which would probably screw up the decryption)?
Bear in mind that these sorts of attacks also work on data in transit. While exploiting things like padding oracles and similar can result in decrypting the enciphered data, it's often sufficient (or possibly even more useful) for your goal to just change it slightly and send the modified ciphertext on its way.
A few examples:
- You have a chance to attack an encrypted file containing a report, memo, or similar. You saw the start of the document in plain text; it started with a sentence like "We have considered the proposal, and won't promote Filipe Rodriques...". You can determine the correct offset into the document, guess at the text encoding, XOR the strings "won't" and "shall", and apply that XOR mask such that it edits the document to now give yourself a promotion.
- You're attacking a voting system, where the tabulated (but not-yet reported) results are stored encrypted using 32-bit integers. You know your preferred candidate/position was very likely to lose, and the roughly-expected number of results (based on polling, etc.) and you know the structure of the data in the file (where each candidate's result will be stored). You can't read the results, or set them exactly, but you can flip a few bits of suitably high order (significance) that will probably make your candidate's numbers much greater. (A data-in-transit equivalent might be to flip some moderately large portion of the votes - say, 55%, at random - before they're tabulated, resulting in an outcome that should have skewed away from your preferred candidate instead looking like a surprise win.)
- You're attacking a machine with an encrypted file system that you can boot (password-less encryption with the key stored on a hardware module of some kind), and log in a low-privilege user, but can't log in a high-privilege one. The disk encryption should prevent an offline attack, but if you know where
/etc/shadow (or equivalent) is, and how it's structured (even though you can't read it), you can plausibly do something like change your user ID to 0 (you know your own ID, you know where in the file and in the file system it will be; you can XOR the relevant bytes with the XOR mask of your current value and the value you want to set, and it'll be set when the machine wakes up). Then, you can boot up and log in your formerly-low-privilege account. Incidentally, this kind of thing is a real risk against disk encryption because there's usually nowhere to store the authentication tag, so most disk encryption lacks strong integrity protection; this is especially one of the weaknesses of password-less disk encryption (such as TPM-only mode).