Yeah, we’ve tried that… it sucked. There is no way for scipy to pin a specific numpy build. (You can pin versions, but not builds.) And then you ask someone to try building numpy from git to see if it fixes a bug, and it makes their scipy starts segfaulting, etc.
Vendoring libraries in wheels works well, but you really want each wheel to be self-contained, and not make any assumptions about any other packages, except for whatever public API contracts they provide. (Usually this means depending on their public Python APIs only.) And to make your wheels self-contained on Linux and Windows you have to give any DLLs unique names. (On Linux, auditwheel takes care of this for you.)
If you want to reliably share DLLs between packages, then, well, conda does handle this case well :-). Or, we could support it for wheels via something like the “pynativelib” proposal I wrote up a while ago, to create Python packages that mediate access to a specific DLL. The technical details turn out to be surprisingly complicated (this time it’s macOS’s fault), but it’s totally doable. But no-one is actually working on this right now.