PEP 518 lists some reasons not to use configparser and I agree with them wholeheartedly.[1] Personally I don't want to use ill-defined formats, even for simple projects.
The only reason offered is that there are (or might be) differences between version of Python, mainly 2 and 3, as far as I can see.
Python 2 is EOL, so that's no longer a concern.
As for differences between Python 3 releases, isn't there a fairly large difference in TOML support as well, since in versions before 3.11 it doesn't work at all? Wouldn't specifying the behaviour of the INI parser as whatever 3.11 is doing (and raising an exception on earlier versions) amount to essentially the same thing?
Newer packaging-related PEPs require TOML, and many developer tools use TOML by choice, but a fresh install of Python couldn't actually read it. That required workarounds from tool and library maintainers, making it more complicated to support as many users' preferences and ways of working as possible.
However you prefer to work, your tools may now be easier to test and maintain. This change is good for everyone.
These files are already in toml, so it's only "unnecessary" if you ask for them to switch the file format.
Otherwise, adding tools to the standard library to read file formats required by the ecosystem is a good idea, regardless of whether you agree with the particular format.
Ini files aren’t a standard though, so every language can handle them differently. As a result they often bite people using them in multiple languages in the foot
These are dev written and Python3 read files, the parser of which hasn't changed in a decade. Everyone knows how to write them. The parser is also lenient and handles both kinds of comment. That's enough for simple metadata.
We have a 15 year old setup.cfg in one project at work, many other .ini's... has never been an issue.
[1] https://peps.python.org/pep-0518/#configparser