TL;DR :: OP should use Kerberos or PAM or some other pluggable authentication method on the MySQL end.

I think the discussion is about the particular case in the thread. It's absolutely true that the authentication system should have one-way hashed passwords. However, the OP appears to be wanting to store actual decryptable, non-hashed credentials used to connect to another system.

Now there are reasons this is a bad idea, and that's what people are asserting. In the OP's case, something needs to decrypt these passwords to achieve what OP is trying to do. Therefore anyone who can access these non-hashed encrypted passwords is likely to also have access to the decryption routine, rendering encryption mostly moot. That's why it's a bad idea.

There are ways to set up a password vault that addresses some of these concerns, but anything that must run from cron is going to have a weak link in security somewhere. The cron system would need access to the vault in this case, so it's still basically plaintext passwords. The only real fix is to use something like public key cryptography.

Thankfully, database software tends to have lots of ways to authenticate. MySQL has pluggable authentication which support Kerberos, PAM, etc. Postgres has its own auth methods including GSSAPI with Kerberos.

Since this is running under cron, there's still going to be a bit of a weak link in that some likely unmanned and unwatched user account will house the private keys, but it's still a lot better than depending on plaintext passwords on disk.

Edit: changed version-specific URL to track current version for Postgresql after a suggestion from erix