As he shows at the end he is clearly writing some mixture of HTML and some custom language that he uses to parse title, tags, and date.
I do agree that unless absolutely needed you shouldn't tie yourself to proprietary formats, but unless you are writing simple notes you probably want more functionality out of your files than actual plain text file can provide at which point you should instead use markdown.
The fact that some other tool can do more with these files, parse them, execute them, "extract" some logic from them isn't relevant to the fact that I can open, read and edit these files as a pure and plain text file.
Therefore adding parsable parts/logic to files like YAML headers (or any self created style) doesn't make these files 'non plaintext'.
Following your logic would mean that doing any markup in a text file would make it somehow 'non plaintext'. I remember old Readme files with headlines being underlined by adding a new line full of - - - - (dashes). And stuff like this. Because these could theoretically be used to parse the files and extract headlines from the text.
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.
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.
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
I'm puzzled, how people use markdown? For what? Just to make text more formal?
The difference perhaps being that the note-taking/creating aspect is done in plain text, and stored as such.