The obvious benefit to encryption is that they have to get multiple pieces of information to decrypt the data (or brute-force it). The strength of the encryption you use will determine how long it takes to break the encryption (assuming the passwords are strong enough; a weak password will fall to any number of variants of dictionary attacks before a more thorough brute-force attack).
If either the encrypted password(s) or the key is compromised, you'll want to change both as soon as possible. If both the encrypted password(s) and the key are compromised, you're in the same boat. At least if it's only one or the other that's compromised, there's a smaller chance that they'll get to use the passwords to compromise other data/systems.
Finally, and this would hopefully go without saying, you want to make sure you lock down the systems and figure out how they got in. If you changed the password(s) and encryption key before figuring this out, assume they got the new data, too, and change it again after you lock them out.
The reason we use hashing instead of encryption for user passwords is simply because it is more secure (because, theoretically, you can't just decrypt a hashed password) and we only need to know whether the user knows the password; we don't need to know what the password happens to be.
In the case of passwords the system needs to perform its own duties, especially passwords which the users should not know (or even be aware of in the first place), you rarely have a choice other than encryption, because you need to be able to retrieve the original password. The only other option is to have some other form of authentication/authorization configured between the two systems (or the web server/application and the service being utilized). In most cases, something like that would be configured transparently, so CI would access the service (say a mail server, for example) as if there was no authentication required.
