It's minimally viable, which means it does what people needs now without costing too much in resources. I'm not Joe (I wasn't even born at that time), but

> a text file (with an undefined character encoding)

Most team kinda have the same system to work from, so character encodings doesn't matter much (and people who deviates from the norm know how to handle such things).

> an undefined structure for the header of the file

That's pretty much YAGNI. By the time you get to this point, you could probably switch to a DBMS and import the old data.

> a rule that status must be 'open' or 'closed' in every human head

A lot of rules, even today, are encoded in human head. In the ticketing systems at $WORK, each team has a different set of fields with different semantics for the status field. And there's a global repo. You can easily enforce that new addition don't have any other value.

> a revision control system which dates changes

No need to wonder how to enforce proper date control. And less code

> a filesystem, terminal, multi-user OS, shell (piping, globbing, environment variables), grep, wc

Comes with UNIX,

> an out of band way to request and obtain permission to change the owner, possibly a high-trust environment with no arguing "you agreed" "no I didn't"

The owner of the ticket? Why can't it be a new update to the file? It's version controlled. And the import to the global repo (which I think is the source of truth) can be monitored and constraints enforced.

> a programmer/scripter who can develop the management reports on-demand

It was 1986. If you have a computer on site, you also have a programmer available.

---

So you got a working solution without investing too much resources solving subproblems, some of which are not even important.