I don't want to entirely forget about it--it's an idea that's been flown before.
And it would solve a lot of problems. But ...
The Mac version of Sigil already includes a fully-functioning, portable version of Python (with pip) included. Windows doesn't. Windows Sigil is creating the correct python environment each time a plugin is run by setting environment variables for the python process that is being launched.
So even if we could make sure that environment is being properly set for pip on Windows (by creating a wrapper for it, or something), there could still be issues with things like upgrades, dependencies and uninstallations.
But if someone ran Sigil's pip (if it was included with Windows) without the proper environment being set before-hand, it would still likely use the system's Python location for determining if dependencies were met, or upgrades were required, before installing a new module (even if the new module were being installed to a different location).
The only way I could, in good conscience, roll something like this out with Windows Sigil is if I could totally ensure that Sigil's pip would only use Sigil's bundled Python to determine if dependencies are installed (or need upgraded), and only if the new modules could be installed in a way that wouldn't affect a user's System Python.
It's a bit of a tall order. Especially to accomplish something that could be achieved as easily as switching to a different external Python interpreter to run certain plugins.