The problem occurs when SF CLI (from the @salesforce/cli npm-repository, not the former Salesforce CLI known as sfdx, or sfdx-cli) tries to download the necessary plugin sources to perform the job of packaging a 2nd gen package version.
Due to the new SF CLI architecture it seems that some plugin namespaces are not bundled with the executable out-of-the-box and thus have to be installed seperately.
This just-in-time installation may fail because of network issues on your local machine. This is most probably the case when working behind a corporate firewall, and when the SF CLI tool was installed by using npm (node package manager) or similar, i.e. by executing $ npm install --global @salesforce/cli
node and npm is partly aware of HTTP_PROXY and HTTPS_PROXY environment settings, or is able to use matching settings from .npmrc. Unfortunately, the inner http client used by sf CLI (or former sfdx CLI) does not seem to regard these settings, thus failing to connect to the internet because it simply ignores your environment's proxy settings. Maybe that I missed some secret settings here, but nonetheless, there is a workaround.
The solution to this common problem is to install the packaging plugin manually,too. Using npm:
$ npm i -g @salesforce/plugin-packaging
Then cd to the installation directory of the plugin in your $NODE_HOME:
$ cd /.../ node-vx.y.z-platform/node_modules/\@salesforce/plugin-packaging/
And link the plugin with the sf CLI executable so that it can be called:
$ sf plugins link
Now the version packaging should work as expected, at least it did it for me.