I can certainly do that, sure. But although this thread never said “don’t consider the steps needed to reach the goal”, it also never said don’t do that, and, at least to me, looking at the first post in this thread and the post it linked to as an example, it sure seems like it was more targeted at “let’s imagine what we want the workflow to be” rather than “let’s think about what incremental steps we can take right now”.
Personally I’m not even super averse to getting the ideas shut down if that comes in form of concrete feedback (e.g., “this cannot be done because of this reason”). Of course, as @pf_moore noted, the people who are able to provide that may simply not have the time or inclination to do so, and that’s their prerogative.
Anyway, just to take a stab at something that’s been on my mind with recent posts: I agree with what @PythonCHB said a few days ago, that the main obstacles to people putting things on conda-forge are social and not technical/administrative. Personally I’d go further and suggest that a lot of the obstacles that exist for Python packaging are just due to the difficulty of navigating the landscape of tools. What would people think about no change in tooling, and simply having more text on python.org that acknowledges that other distribution/install channels besides the pip+pypi combo already exist and are widely used? And perhaps suggests that people try them out, or offers some kind of summary of the options?
My hunch is that people will say that’s “out of scope” somehow. 
But we already have multiple build tools listed in the pypacking docs with no explanation of how or why someone might choose between them. Why not expand the perspective that the official docs give?
I am used to it, that’s why I use conda, and why whenever anyone expresses their frustration with this whole situation I suggest they use conda as well.