My initial reaction is "no", and that this request kind of rubs me the wrong way. In the pull request you say:
But the blog post you quote is just saying to run "python -m build" instead of "python setup.py", not to entirely remove setup.py, or that using setup.py as a configuration file is deprecated. In fact, the highlighted tl;dr at the top of the post says exactly the *opposite* of that!
Setting that aside I also am, in general, strongly against Django being an early adopter of any new packaging tool. While it's certainly helpful for the tool, because our user base is large enough to uncover all sorts of edge cases, it's not great for our users, who then get to be beta testers against their will. I went through this myself with the code formatter `black`, which was an eager and early adopter of several things and as a result would break my CI pipelines every couple of months when one of those early-adopted things had unintended side effects. Doing that to Django's user base would be bad for our users, bad for Django ("why does Django keep breaking?"), and bad for Python ("look, if even these high-profile packages break all the time, Python packaging must really be as terrible as everyone claims it is!").
So for now, the non-setup.py packaging ecosystem is still rapidly developing and still has rough edges. Maybe in a few years when the situation is improved, Django can adopt new and solid standard methods of doing things. But for now, the solid standard still very much is setup.py and the setuptools build backend.
About all I could support at the moment is switching the Makefile that release managers run to use `python -m build`: