The file format is irrelevant to the security of the data transport. You can send plain text as well as arbitrary binary formats securely through an encrypted TLS tunnel. Without transport security, the data can be captured either way and would only be protected by encryption in the format itself.
With regard to security on the application layer, zipping sensitive data has historically been a popular measure against a class of web application attacks related to content sniffing. E.g., depending on the format of the secret data and the predictability of the download path, you might introduce a cross-site script inclusion (XSSI, not XSS) vulnerability by offering plain text downloads without appropriate security measures. Here's an imaginary scenario to explain the attack:
Let's assume any authenticated user on your platform can download a user-specific sensitive configuration file from this URL:
The config file has the following format:
user_id = 314159
secret_token = "719fe66f5159f86e798eabf930b8c9c2"
Now an attacker could simply send you a link to a prepared website with the following content:
What happens here is that your browser interprets the response from the download link as external JS code and thereby leaks the values of
secret_token to the embedding attacker-controlled page as global JS variables. Zipping or reformatting the data in some way would have prevented this attack because a ZIP file cannot produce valid JS code. While this specific case might appear far-fetched, there have been many other sniffing-related vulnerabilities in the past.
Note that the correct and modern way to mitigate this XSSI scenario is not zipping the file but sending an
X-Content-Type-Options: nosniff header that forces browsers to only accept JS with a correct MIME type, and sending a
Content-Disposition: attachment header that instructs browsers to not display the download inline.