Does Encryption add difficulties to File Recovery? Seems Yes. People always tell us, it is very hard (or almost impossible) to recover an encrypted hard disk.

But after a second thought. I think this is not true.

Given that we know the KEY, and the method/algorithm of decryption, the decryption(key, encrypted_data) should be no different from plain text.

For example,


We mistakenly deleted a file. We have to examine the bits on the hard disk, identify the start and end positions of the file, and un-delete it. Of course the bits on the hard disk looks meaningless. However after decrypted, it appears no different from an ordinary hard disk.
Bad sector happens to the hard disk. For those error bits, those bits are lost, no matter encrypted or not. (Of course you can guess those bits and recover them.) For the rest intact parts of the hard disk, we can still decrypt those files as normal.


However there are some concerns that I am not clear about.


As some (or most) disk encryption algorithms are chaining previous and next sectors. Will this lead to whole hard disk not recoverable with just one error bit?
Consider the "bad sector example" above. If an error bit falls on an JPEG file. With a normal hard disk, we can still view the image, with display error on certain parts only. However with an encrypted hard disk, will encryption leads to whole image not viewable?


All-in-all, given that we know the KEY, and the decryption algorithm, does Encryption still add difficulties to File Recovery?
It depends on the circumstances, whether encryption will cause difficulty while recovering files. If you have your physical drive damaged then chances of recovering the data in the first place (encrypted or not) are bleak depending upon the extend of damage. 
First let's think of this hypothetical situation when using file system level crypto on the contents (files) of a drive: If I have an algorithm (that does not use chaining) that uses encryption  with authentication to encrypt the contents of a drive. Say, my drive got physically damaged, but the damage was to a small extend. It so happend that the "error bits" were on a JPEG image. If I decrypt that content from my hard drive, my software would give me an error stating that, the file / content has been damaged and its integrity can never be trusted and would refuse to decrypt it. But If I know the algorithm and the key and I make a custom software to decrypt the contents of the file no matter what, I might get a decrypted JPEG that may be partially viewable/cluttered at some places. But still in essence the data is tampered and the whole purpose of "authentication" has been compromised! 
But the above situation is practical if we are using file system level encryption/ decryption and that is why it is more recommended to use it than FDE (full disk encryption), at least you can view parts of the image / file.  But still the algorithm itself opens up difficulties 
if I used AES CBC with HMAC to encrypt my file then the block where the error bit occurs, the decryption becomes cluttered and meaningless, and also alters the output of the decryption of the adjacent block but if I used a stream cipher like XChaCha20-Poly1305 the error byte will be meaningless, but I get the rest and in both cases the authentication tags will not match as a result of the errors in the data in the first place. 
Secondly, if I used chaining algorithms AES CBC to do FDE full disk encryption, then the error propagates, from the block where the error occurs and also affects the bytes of the next block getting decrypted . It is mostly due to the fact that the encryption function themselves have an avalanche effect when their input bits are changed giving totally different outputs ! 
At most if you use chaining you loose blocksize*2 bytes of data for blocksize bytes error in a block. For AES this block size is 16 bytes. 
Therefore it depends on the algorithm that you use and also the circumstances in which they are applied.
In practice we use AES XTS as the defacto standard for full disk encryption:
See: 
Disk encryption theory

AES XTS

Hope you understand what I wanted to convey...