Thats not really true as generally IoT nodes will manage the traffic they generate to avoid synchronisation with other nodes.
For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks.
This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming it.
What you propose is one way of doing so. Again, I remind you that an IoT SaaS has multiple tenants and these tenants can't be expected to collectively coordinate. And in certain domains, it is not possible to dictate timing requirements to the client tenant and thus enforce the (SaaS) providers traffic requirements.
I don't know the specifics of your architecture, but if your (multiple) tenant applications are sharing code on the node-side, then it follows that they can self-organise in a similar manner.
For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks.
This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming it.