Since the context is systemd, one really should look to Unices in the 1980s rather than to Microsoft Windows in the 1980s. INI files were popularized by DOS+Windows, where there was no formal specification and whatever the Win16 API happened to do was gospel, but were largely nonexistent as a file format on contemporary Unices. Far from being "the" configuration file format, they were barely a blip on the radar and their introduction into Linux was somewhat akin to an invasive species as the Unix world had plenty of file formats and tooling for such formats before then, and the Linux-based operating system world had been busy cloning them all for years.
Things like rc files for shells and .mailrc for BSD Mail were simply scripts written in the program's own command language. The .newsrc used by ReadNews was an example of a common colon-separated key+value format, also seen in Xresources and others. The sendmail.cf used by BSD Sendmail was its own very special thing, indistinguishable from modem line noise.
BSD also widely used the "capabilities" file format, which still exists in many parts of FreeBSD, NetBSD, and OpenBSD to this day for various things such /etc/login.conf and /etc/gettytab and termcap. (In many cases nowadays, cap files are compiled into Berkeley DB or other constant database files by tools such as cap_mkdb and tic.)
Many configuration files in the Unix world were simply flat file tables, with colons, whitespace, or TAB as the field separator. phones(5) is one such TAB-separated table that is in FreeBSD to this day.
> Many configuration files in the Unix world were simply flat file tables, with colons, whitespace, or TAB as the field separator.
The main reason this was done was for shell scripting. Bash and Bourne, unlike newer shells like powershell, don't have any notion of structured input/output. It's string all the way down. So these simple table-like files with field separators were a way to put structure into those strings. It works out nice, because they play really well with awk.
But, such formats are a bit awkward now. You have to remember which program uses which field separators.
You mean you don't like INI because it's a Windows thing? But you also have it in .desktop files, git configs, php configs, samba configs, gtk config files, kde config files, it's a standard config file format for all Qt apps (QSettings).
JSON was popularized by web browsers, yet some people use it for configuration for system desktop apps, which have nothing to do with JavaScript. If usage of JSON is not a problem, then why popularization of INI by DOS+Windows should be a problem?
If you think INI files were a blip on a radar then you might not realise their real popularity. They even have support by the operating system api (WINAPI had support for INI natively, ReadPrivateProfileString). Unless you say that they were a blip on a radar on Unices in the 80s, then I probably would agree.
By the way,
> as the Unix world had plenty of file formats and tooling for such formats before then, and the Linux-based operating system world had been busy cloning them all for years
And that was probably a good motivation to use something established and standard, like an INI format.
> You mean you don't like INI because it's a Windows thing?
No. That's you writing that. I wrote no such thing.
> Unless you say that they were a blip on a radar on Unices in the 80s,
Which is indeed what I wrote.