Nobody is pretending that, as far as I’m aware. What is happening is that a significant group of users (significant enough to justify that “wasted engineering effort” you refer to) are not willing to accept the trade-offs that using conda would involve.
For a “Python language packaging vision” we need to address the position of conda. Is conda part of that vision, or is it a separate, specialised, ecosystem that remains forever as an alternative to the core approach?
If we treat conda as an outlier, a specialised ecosystem unrelated to the “Python language packaging vision”, then binary dependency management conda-style is indeed “out of scope” for Python packaging, because “use conda” is the response to people who want that. But people who are in the core audience for the “Python language packaging vision” have made it abundantly clear that they want access to libraries like numpy, scipy, sklearn, pytorch, etc. So the vision needs to look at how to make it possible for the developers of those libraries to make them available to that set of users. And “use conda” is not the answer, so “conda solves those problems so you shouldn’t try to make wheels do so” also isn’t the answer.
If conda is part of the vision, it needs to change, probably quite significantly (to meet the needs of those people who currently don’t use it). Only the conda developers can decide if they want that much change, but if they do, then we (the conda devs, the PyPA and the packaging community) need to get together, because there’s a lot to do…