INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library and would reliably generate internal config representation (e.g., read config file into an object in application memory that will be used to modify the behaviour) is a good thing and TOML helps with that while INI does not.
If you would de-serialize an ini-file into Objects in memory you would typically have meta-data about your object (RTTI/Reflection for compiled languages, given for scripting languages).
But yes, INI isn't without flaws. Parsers typically will need to accept everything from "true", "True", True, true, 1, "1" for boolean fields.
From what I see, 20+ years proven parsers are available for pretty much any language there is.
And yes, the format is a bit flawed. But it gets the job done.
There is no "ini format" though? INI is a weak set of conventions that different programs parse in a completely different way, it's the opposite of standardization.
For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format.
TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS.
And again: If your config files are so complex, how about just creating a TUI/GUI so the user can configure your program in an accessible fashion?
Anyway, yes, there is something that can be improved: Create a standard instead of adding another layer of complexity for something that should be very simple in the first place.
Yes, binary size may feel arbitrary, but it often gives a hint about the hammer's size.