Does knowing the file type of an encrypted file make it easier to decrypt?
For practical purposes, no.
Against good crypto, using modern ciphers and making no major mistakes such as a padding oracle or ECB mode or other weakness, it doesn't really help. It can theoretically act as a test for whether you brute-forced the key correctly - does the decrypted file contain the right magic number and data format? Good, you got the right key - but actually brute-forcing the key should be impossible for any modern widely-used cipher (even the weakest form of AES, with 128-bit keys, would take centuries for even a nation-state to brute-force, even assuming Moore's Law continues on course; using only modern hardware it would take many orders of magnitude longer).
Of course, people do make mistakes in crypto, and some ciphers that were once thought strong are now known to be vulnerable.
If you know that the file was encrypted in a particular way, and you know of a weakness in that method, then you can attempt to exploit that weakness. This might be made easier by knowing the file type, as some files are generated by software which nominally supports encryption but implements it very weakly, and knowing that the file is of that type will suggest you might be able to try such attacks (though it won't help you if the file was encrypted using some other tool that implements the crypto correctly).
The ECB (Electronic Code Book) block cipher mode of operation mentioned above encrypts every block (typically 16 bytes for modern ciphers; historically often only 8 bytes) using the same algorithm (for a given key), no matter where it is in the message. This means that if you break the message (or any number of messages, if they were all known to be encrypted using the same key) up into blocks and find two identical blocks, you'll know they're the same plain text. If you find such duplicates and know at least some of the plain text of one of them, because you know at least part of the data of the file (due to knowing its format, or for other reasons), you now know the plaintext for the same part of the other block. This can also be useful when you know the data format in general even if you don't know any specific bytes in it, especially if it's low-entropy data such as a simple image file; see the link above for a striking example of taking a bitmap image, encrypting it using ECB, and the ciphertext (if rendered as a bitmap) still largely revealing the content of the image.
There are other attacks that are less likely to be relevant here, but might be relevant in other situations. For example, if you can get the same data encrypted many times using the RC4 (sometimes called ARC4 or ARCFOUR) stream cipher, you can exploit biases in the "key stream" (the bits generated by the pseudorandom function that a stream cipher is) to slowly decrypt the data; this is why RC4 is no longer trusted for use in SSL/TLS (although for a given blob of data encrypted only once, this attack isn't viable). Padding oracle attacks allow you to decrypt a message (typically one encrypted using a block cipher such as AES in the CBC mode of operation) in linear time, provided there's an "oracle" that knows the decryption key and will, on command, decrypt any message and tell you if the padding (padding is necessary for block ciphers) is correct. Such an oracle is usually not available for a file at rest, but a padding oracle is the reason the that CBC mode can no longer be used in SSL, and led to the deprecation of the entire SSL protocol (TLS includes protections against padding oracle attacks).
Knowing the structure and some basic data about the file can also enable bit-flipping attacks (where you don't decrypt the data, but do change it in a predictable way that could further your causes against whoever legitimately uses the file). This is getting pretty far afield of your question, but it's sometimes relevant when you're attacking an encrypted file of which you have minimal but non-zero knowledge.
Yes in the sense that it is easier to detect when your brute force has tried the correct key. If you know it is a text file written in English, you can check the letter frequencies. If it is a format that has header information, you can check if the header makes sense. If it is an executable file you can check if the distribution of codes is close to reasonable. If you don't know what file type you are looking for, how do you know when you have found the right decryption?
Potentially - yes. Such information reduces entropy and thus requires less attempts to brute-force it. But I say potentially, because it holds only if the attacker can really improve his brute-forcing algorithm for a particular file type. And this is far not trivial. One of the reasons is that at the beginning of encryption data are usually transformed by applying some random data, e.g. by applying xor.