Oh, but it also differentiates between text and binary files. Binary files are sent as-is, text files are sent line by line with a \r\n terminator. .\r\n indicates the end of file. Leading .s must therefore be doubled. And then directories are sent in another format (type/name, path, hostname, port -- tab separated).
Which means the client has to know before hand if it's a text or binary file or directory. How does it know that? Well, there's a 1-character code at the start of the filename which gives the filetype. 0 is a file, 1 is a directory, 9 is a binary file. There are also other filetypes which will make you reminisce about the 80s (Unencoded file, BinHexed file, n3270 session, etc.
The whole text vs binary reminds me of FTP, and most clients there defaults to requesting everything as binary transfers.
Edit: MIME is no cure-all, i wonder how many times i have seen Firefox get royally confused because the MIME type is wrong.
1. your url looks like gopher://dipstick.io/0file or gopher://watchingpaintdry.museum/9folder/file. The filetype is part of the url, but only the client is aware of it -- it's not passed to the server.
2. When using a URL, the client has one idea of the file type but it does not necessarily match what the server thinks the file type is.
2. Error messages. HTTP has a status code to indicate the file doesn't exist (or was moved, etc). Gopher can send the error message back as the payload but... is that in text format or binary format? The server has no idea what format the client expects.
Always sending binary data and using out-of-band status codes and file type just keeps life simpler.