As you said, when using a string comparison function which hasn't been designed to resist timing attacks, then it can be exploited to guess the string with which you compare.
Comparing unencrypted and unhashed strings will indeed leak the original string, be it a password (either stored in a database or hard-coded), a session ID, an email address or a multi-factor authentication token - meaning this attack is not limited to the common sense of "passwords".
If the strings are encrypted and the encryption function is known to the attacker (with the associated keys), then they could guess the encrypted string, then decrypt it to get the original string.
If the strings are hashed and the hash function is known to the attacker (and the associated salt, if there's any), then guessing the hash will be harder and harder each byte (due to the avalanche effect), making it very hard to guess more than the first bytes of the hash, but that may be enough to bruteforce if your original string has not enough entropy.
This recommendation is true when you're comparing any user-supplied string (either you hash it or not) with any type of sensitive data (see above, I personally consider that any information related to one user is sensitive).