Google will disagree with you: chrome://settings/passwords

libpurple/Pidgin could absolutely provide a more secure alternative by either using an OS keyring, or following Firefox's approach and requiring the user to type in a master password every time they start the client.

Is there any situation where this sentence would be true?

People disagreeing tend to reply with blanket sentences like "if there is a process reading the files owned by you on your computer, you're already doomed", ignoring that security is made always made by layered levels, it's not an black/white issue. A file on disk could for instance end up in an unencrypted backup that goes into a server which is then exploited; it could be in a VM where you cannot control the supervisors. It might be end up being mailed to yourself for mistake while migrating computers (I know many people who do it), and thus being stored on remote servers; you might be running on a NFS-based deployment where you don't want to necessarily trust all present and future sysadmins with your personal passwords.

What's worse is that there is an alternative, safe solution to this which is using the operating system keyring, which stores passwords fully encrypted, and also enforces per-software / per-process ACLs ("app X wants to access your password for Y, do you want to allow?"). Pidgin (and other multi-platform software) tends to be resisting to this because it requires even more OS-specific code to be added and tested.