I do not agree with this request.
The delay configured via "Quiet time" must always be enforced without exception.
If you start making exceptions (like the one proposed by the OP) things start to be confusing.
You could at least update the description of this configuration. This is now:
When this option is checked, newly triggered builds of this project will be added to the queue, but Jenkins will wait for the specified period of time before actually starting the build.
For example, if your builds take a long time to execute, you may want to prevent multiple source control commits that are made at approximately the same time from triggering multiple builds. Enabling the quiet period would prevent a build from being started as soon as Jenkins discovers the first commit; this would give the developer the chance to push more commits which would be included in the build when it starts. This reduces the size of the queue, meaning that developers would get feedback faster for their series of commits, and the load on the Jenkins system would be reduced.
If a new build of this project is triggered while a build is already sitting in the queue, waiting for its quiet period to end, the quiet period will not be reset. The newly triggered build will not be added to the queue, unless this project is parameterised and the build has different parameters to the build already in the queue.
If this option is not checked, then the system-wide default value from the Configure System screen will be used.
It does not say anything that by "triggered" you do not mean "triggered" by hitting "Build Now".
By the way... is triggering a build via "Multi Job" "triggering"... or?