Do you think that the alternatives failed because they weren't 'spot on'? Perhaps they failed because it's a much harder problem than they recognized when they started out.
I don't think it is correct that "they don't have the choice". Reliance on EUDAs in Excel is a well telegraphed problem for literally decades. There have been lots of attempts to solve it, whether by apps which seek to replace Excel, addins or things which work with Excel, programming interfaces, changes made by Microsoft to Excel itself, alternatives such as Jupyter. You needed to know about these and understand to what extent they succeeded and why they failed. If there's an opportunity for your tool, why is it different to all the other solutions?
If you think that there is 'no good reason' why excel users couldn't pick up some coding, and 'no good reason' why developers shouldn't make business reports, you should think about those questions harder, and try to understand what the reason actually is, not worrying about whether it's good or bad. Your not understanding why people do something is not going to make them stop doing it.
The thing is that using setuptools is neither standard nor Pythonic. It isn't part of the standard library. It's a way of doing things that is broken, and has been specifically called out by the Python developer community as something that people should stop doing.
72MB? On a development machine? Are you on dialup?
Poetry doesn't fragment the ecosystem. Unlike setuptools it uses pyproject.toml, which can be read by other tools, and is the correct way of storing package configuration.
A package built using Poetry is installable without Poetry in the exact same way as one built using setuptools.
I don't recognize this. I use poetry all the time, without setup.py and the local installs are editable. I have published half a dozen packages which don't have a setup.py and they all work fine.
I know Python much better than I do rust or node, but I think the Python design decision was decent here: you can use different tools, but all of them should put the configuration in pyproject.toml. That file has fields which are universal and others which can depend on the exact tooling used. So build tools, repos and so on can get the info they need and at least potentially, do the right thing for code packages with different tools.
This is bad advice. Do not create a setup.py for a new package. (Keeping setup.py for an old package can be okay.)
The author is correct that you want a tool such as flit or poetry which will work with pyproject.toml. Setting up a basic package will be no harder than using setuptools, and it is much more future-proof. You won't have to copy-paste some other crufty setup config either.
It is fair that you don't need all the external tools in this tutorial. In particular, using make is very silly since you can configure different linting and testing workflows directly in pyproject.toml, rather than pull in a whole other system which only works decently on *nix. Poetry also removes the need for tox.