The idleMinutes feature is nice since it will help jobs sometimes avoid pod creation delays but other strategies would also be very beneficial. 

Pod creation delays can be time consuming, approx 30-60 seconds depending on pod image size. The creation delay is often several minutes when using Kubernetes horizontal node auto-scaling. Nodes typically take several minutes to come online. The combined delay can often mean that it takes 5 minutes for a job to be started. 

idleMinutes set to a long value can help retain pods but you might retain too much capacity and prevent k8 cluster scale down.

idleMinutes set to a short value increases the chance to a job may encounter pod creation delays.

Web servers such as Apache's HTTPD have a minimum spares concept where they will maintain a number of pre-created processes so that incoming requests can be handled without delay.

If implemented for the Jenkins Kubernetes plugin the minimumSpare would need to play nicely with both idleMinutes and cluster concurrency limits. Worker pods are would still be retained for idleMinutes and after that time they would be released if doing so would not decrease the spare pods below minimumSpare. When starting up the kubernetes plugin the minimumSpare numver of worker pods would be proactively brought online.

The Jenkins Amazon EC2 plugin supports this concept using a configuration option called minimumNumberOfSpareInstances