I think my approach would be to generate a file in Markdown, then import that into a good Markdown editor. You could generate it each week or month from a template, making it easier to add repeating tasks like exercise and dog walking.
For me the best parts are:
1. You could write a parser very quickly.
2. It's very easy to edit and add to as a human.
3. It can easily be tracked in git or via a diff-based tool.
I did already think about the repetitive tasks, a long time ago I used to have a tool that would look at the past tasks and recommend future tasks (with appropriate distributions). One example was booking a dentist appointment every 6 months, even if I forgot to schedule something it would remind me to book one in, dismiss it or push it back.
Although, TBH, the OP's suggestion of one-line-per-day puts too many items on the same ling. I would have gone with one line per event. Yes, there's more repetition, but you need no out-of-line context, you have to do a lot less parsing, and you can look at a fixed number of _columns_ and get the beginning of the description of each event, which is nicer for manual searching.
I think that it's far more important that it is human readable, if it becomes too tricky to edit manually, then just go with a database.
Periodically my task system fails (the Taskwarrior 3 disaster being the most recent) and this is pretty much what I end up using. But then I forget a bill or something important because there are no bells or buzzers keeping me as a useful working unit. Then I erect the previous system, or some variant, and go with that until some inevitable breakage sends me back to paper. So it goes...
These days I have a little A6 lined notebook and manually list tasks there. Each page is a new day and the tasks are listed similarly. The only modification is that sometimes I put some letters to theme a task, i.e.: