I'd argue that using "plaintext" for structured data (a.k.a, inventing your own data representation) will set up both you and the users of your dataset for unnecessary pain dealing with unescaping and parsing.
It is way easier to input / type and change / update. And compared to lets say JSON, YAML or friends at least 5x times more compact (less typing is better). See the world cup all-in-one page schedule in .txt [1] and compare to versions in JSON, XML and friends that are page long dumps, for example.
[1]: https://github.com/openfootball/world-cup/blob/master/2018--...
Example: I assume, the scorer lists are actually lists-of-lists, where equivalent JSON could look like this:
[
{"player":"Gazinsky", "goals":[{"minute":12}]},
{"player":"Cheryshev",... which is absolutely more verbose.
However, if someone just went by the data, they could get parsing wrong: It looks like the outer list (of players) is delimited by spaces - however, there are also spaces inside the player names. A better approach could be to split the list by ' signs as each player has at least one time - however, players can have more than one time and could probably also have apostrophes inside their names (e.g. Irish players). So I guess, the best delimiter would be a letter after an apostrophe after a number. Except, we might also have parantheses, etc etc.