I use them as follows:
If that category includes slightly more elaborate formats, like YAML or properties files, then it's the best option for whatever you expect people to read and edit by hand. Another huge advantage is the simplicity of modifying it via a small script (e.g. sed).
Nothing beats the simplicity and ease of use. When the support team has to configure something on a remote machine (e.g. solve a client's problem), or IT has to reconfigure a bunch of servers that run your software, they'll thank you for choosing this format. It'll also save you from writing some one-off software that does that for them.
I agree with @Ingo here - unlike plain text XML is harder to process via scripting, and a nightmare to edit by hand imo.
Still, if you have data with some elaborate structure where YAML becomes indecipherable and still want it to be human-readable and editable, then XML is probably the best choice.
A great choice for when you have lots of data (that would make plain text and XML cumbersome) that you may still want to allow 3rd parties to edit manually - via SQL commands and even GUIs.
Another advantage is that your code that manages the contents is very readable. @Richard-Harrison gave a good list of other advantages in his excellent answer.
One advantage over RDBMS is scalability through distribution, which is probably not very relevant to your question. The advantages that are probably more relevant are the simplicity of a key-value store and the flexibility of schemalessness (is this a word?). When you find yourself breaking the relational paradigm: just storing blobs to the database, accessing them by key, and processing them through code, then consider this option. Some choices (e.g. CouchDB) are very portable, have a small footprint and can also scale so they offer a good non-relational alternative to MySQL and SQLite.
The advantage of binary is that it's fast and compact. When the only thing that needs to read and modify your file is a program and the data doesn't fit the relational paradigm or speed is really important then this may be a good choice. Probably the best fit for media files.
I should point though that I've yet to encounter a case where simple access to program data isn't required at some point for reasons that weren't considered during the initial design. Nowadays I personally go for the database option for anything other then files that have standard formats and need to be encoded/decoded by other software (e.g. audio, video).
Note: there's a common misconception that binary is opaque and thus somehow more secure. Without additional protection it isn't - if someone wants to hack your software then simply storing your configurations or whatever in binary won't stop them.
Not really an alternative to the above, but rather an extra measure.
Advantageous when you need to transmit things over the network, or when you store lots and lots of data and want to save space. Note that storage space is usually abundant these days, so consider your target platform.
Performs very fast on almost anything today (Moore's law in action, baby), so the only reason not to use it is that it adds complexity to your code. Not a lot of complexity, but still a violation of the KISS principle. Especially cumbersome for configuration files that need to be edited manually or via scripting - and if you really need to save space there, then you should probably use the database option.