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.
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.
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--...
https://github.com/openfootball/england/blob/master/2019-20/...
To properly parse this file you need to write a parser that cut fixed-width fields (wait, are the team names padded to fixed-width or is the '-', which doubles as part of the result, a delimiter?), trim strings, knows that "Aug/24" is August 24th, deals with wrapping of the months over the two years, is sensitive to indentation, and understands that "Matchday [0-9]+" and the [] bracketed dates are section delimiters. And what about that first line beginning with '=', comments? Where is the formal grammar for this format?
CSV of "matchday,fulldate,team1,team2,result" would be just as easy to read, much easier to parse, and probably smaller in size
The point is as you say - the .csv format is easy to read / parse / write with a script for automation BUT it's way harder to start from scratch to input / type and keep it up-to-date. That's why you need both type of formats (one for hand-writing and one for easy auto-generation).
The best generic tool for managing (structured) data is SQL. Once you have the datasets imported (via the custom readers / loaders) it's just plain SQL (and works with SQLite, PostgreSQL, MySQL, etc.)
For small to medium-sized datasets, a nice middleground would be SQL dumps. Put the dumps in Git for versioning and diffing, and load them into $DATABASE for actual queries.