The vSphere plugin 2.13 has a facility to define a slave "template", allowing Jenkins to ask for more slaves to satisfy build workload demands.
However, the implementation is currently limited to only SSH-launcher slaves (with hard-coded settings too), and with a "retention strategy" limited to only "run one build then dispose of the slave" (with a hard-coded timeout).

This has two negative implications:
1) a Windows slave connecting via the Java Web Start method (JNLP) will cause errors in the logs as the SSHLauncher fails to connect.
2) in situations where builds complete quickly, Jenkins can spend longer waiting for each slave to start up than the build takes itself, which isn't very efficient.

The docker cloud implementation allows for different launcher methods and different retention strategies - the vSphere plugin should be similarly enhanced to:
1) Allow the slave connection method to be configured, exposing all configuration options for each of the connection methods.
2) Allow the slave "retention strategy" to be configured, exposing all configuration options for each of the connection methods.
3) Add a new strategy (e.g. based on the Jenkins CloudRetentionStrategy) to allow a cloud slave to be reused for multiple builds.