I was under the impression that a salt value was inserted into a password to make it even harder to crack.
A salt does not give any security against cracking a single password, it only ensures that two encryptions of the same data using the same password don't result in the same ciphertext.
So if you need that depends on the data you want to encrypt. How likely is it that two people use the exact same password for the exact same data? If you encrypt password lists that includes usernames and passwords, the probability is pretty much none because this would imply that two different people have exactly the same accounts, making them the same person. So no new information can be extracted from the second version of the same data.
About IVs, when using block ciphers like AES, you need a CipherMode. The default mode thats used by DCPCrypt is CBC. CBC requires an IV, therefore to answer your question, yes DCPCrypt uses IVs.
About your quote and the need to protect the IV, this is talking about a very special circumstance, an attack called BEAST on an encrypted TCP stream where blocks can be injected into. The vulnerability requires the ability to inject your own message into the encoded stream to be encoded with the exact same (unknown) password than the rest of the stream. Then you can craft a message such that the IVs cancel out and you can basically encrypt a message with the same key the original message was encrypted. You can then just try to encrypt all possible combinations of that message until the result is the exact same, you found out the plaintext.
This attack is only feasable if you know most of the target message and only miss a few bytes, otherwise this is just a bruteforce attack.
So the question is, can malicious data be injected into your datastream and then, how much of the data you encrypt is known a-priori.
For BEAST this is actually a real problem, as this targets HTTPS, where untrusted javascript code can inject data into the TLS encrypted TCP stream, for example using record splitting, and as the transmitted format (HTML, JSON, XML) is usually pretty strictly defined with only a few variables in there (usually a webserver sends templates with only a few customizations), this attack becomes viable.
But this is a very special setup as this relies usually on injection vulnerabilities (usually by browsers that load malicious javascript). It therefore is made possible because browsers implement a fully fledged scripting language interpreter that executes any code it is given.
If you for example encrypt a file, there is no way to keep the IV a secret, because it must be stored besides the file. This is also not really a security risk, because the encryption stream is usually only used for exactly that file giving no possibility to inject malicious data into it.