The whole point of them is to enable doing things that no tooling can sanely automate, enabling the environment from those builds to be available to do those things. Which is admittedly trying to do two incompatible things at once (propagate the build environment sometimes but not always, with no way to know which is intended); if you have a good answer for that one, I suspect many people would like to hear it.
Stack has this a bit easier in that it can just expose its own environment, but it's also by design and intent less flexible than cabal new-build: reproducible builds means a static, predefined environment instead of the dynamic but constrained one presented by cabal new-build. Each tool has its own purpose and use cases; but while cabal new-build can produce frozen configurations emulating stack, there's no reasonable way to get a dynamic configuration from stack. The flip side of which is you need those environment files to get access to new-build's current/latest environment. It's definitely "wrong solution", but nobody has been able to figure out what the right solution is yet, or at least not in a way that works the way ghc does.
(Which points to the further issue that how ghc works is itself rather limiting, thus stack and cabal trying to impose alternative solutions on it. But changing that is an even more tangled hairball, starting with "what exactly do you change it to?". Which might not have the same answer for stack vs. cabal, to say nothing of other build tools that might be in use e.g. in corporate in-house programming and that nobody outside them knows anything about.)