I poked around a bit and it seems to basically work like this:

1. The cmdlet uses the existing PowerCLI connection to vCenter, telling it to run the command on the VM.

2. vCenter connects to the respective ESXi host and tells it to run the command, but does not receive the output to give back to the client.

3. Instead the client waits for vCenter to give him the "it's done" signal, and then the client connects to the ESXi host to grab the actual raw output being returned from the command.

4. PowerCLI displays that output on your console.

This means your command actually has been executed, even though PowerCLI spilled the error of not being able to connect just to grab the output. I suppose that request is being done with a generic .NET web request method that use the system's proxy setting.

Here you can see an example of such a request from the client directly to the host (I ran the "whoami" command btw). It's really nothing but a very basic SSL'd HTTP request with a token and the response being nothing but the command's output:

I think this is a very odd way to handle Invoke-VMScript. It's not clear that the command has actually been executed and the host is being accessed by its IP in the HTTP host header instead of it's DNS name (with which the host is registered in vCenter and on which the SSL certificate is bound), meaning the client won't actually validate the SSL certificate presented as a browser would (and the SSL request is without SNI as well).