I am not too knowledgable about Python to tell you exactly.
But let's take Common Lisp for an example and why I don't feel the need for a scaffolding tool. Well, actually I do need _some_ very basic scaffolding, namely: create two directories called src and tests + add two very short project files with my names and project names embedded in them, along with a couple of package files. Nothing fancy and certainly nothing that's particularly problematic. Everything that's part of the project code (such as package description with imported symbols and such) maybe be done by using a macro from an external library (ex: certain functions of some library that I import in each of my projects).
But you are right anyway, not everything is a language-specific problem here, only the stuff that gets repeated in code, from one project to another. In CL that includes documentation and the testing framework (from the article's points). Well, the build/project description is just a macro too. Anyway, I didn't mean to diminish the major points of the article in any way. The author is right about the fact that generators are not aware of the user's changes and that can be problematic at times (as with his license and license metadata example).
If I start a new Python project I have a short checklist I go through
1. Poetry (dependency management) 2. pyenv and pyvirtualenv (execution environment management)
Just these two are somewhat of a headache to get going. Once they're up, though, they do the job they're supposed to in an admirable fashion.
How would a language with homoiconicity and macros handle this?