Just use the good old file program and you'll see that in any coherent world we classify python, php, html, and js files as different from actual plain text files.
This very much feels like you are trying to argue tea is same as plain water.
As said. There is no technical difference between a txt or a php file. I can both run through cat and grep stuff.
Are there special programs that interpret the contents differently? Sure. The same with the difference between a php and a py file. Different interpreters doing different things because of different definitions how to 'read' the content.
All pure text, just different languages.
To borrow from your metaphor:
One is Earl Grey. One Darjeeling. One might be Green Tea. One (God forbid) herbs as tea.
You can also cat and grep binary files I guess everything is plain text
Open up a word document (.docx) in hex editor (head -80 foo.docx | xxd) and you'll see it's not a plain file on a binary level. Now do the same with any python, php, html, and js files and you'll see that they're plain files.
That's the difference that Derek is talking about.
If you don't see difference between plain text files and text files then that's pretty much it for this conversation.
EDIT: just to hammer this point home; if you gave me a task to write a report in plain text and I delivered a .txt file with some custom markup language, would you consider the task to be completed satisfactorily? I wouldn't. You can argue that the specification of the task didn't exclude custom markup language, but any sane person would understand what plain text file means.
All version controlled in git.
A few markup headers. Text formatted in markdown. Later combined with a bit of templating logic to ensure different looks (one for client and one for agency) when translating it into the final designed report.
Actually more efficient than creating the two target documents with design from the beginning as the reports quite often changed in structure while being prepared due to changes in requirements.
Separating content from (re-)presentation was a time saver.
I don't think your argument holds any water.
By transforming file Foo.docx into file Bar.b64 you get a plain-text file (Bar.b64) but Foo.docx still isn't plain-text. That's actually how email attachments work (transforming any file into b64 plain-text file), so I think your counter-argument is pointless.