We've done something like this with internal forms. We didn't want 1000+ people trying to do it at the same time, so we break it into groups based on some kind of identifiable attribute.

Usually we would break it up by Employee location. We set the workflow up to run on a subset by adding an input token to the workflow and adding that as a query filter.

Next, we set up the "scheduler" workflow that loops through each location with a delay after each iteration. The scheduler workflow starts each batch by passing in the location/filter.

You can use hidden fields to temporarily mark items with workflow to be ignored in your next search. If your clearing them out at the start of a new day (setting a value to blank on a non-templated field will remove it). Create a field called WFTag or something and set the security so no one can see it, it can be appended to any entry even if it is not part of a template assigned to the entry.

Then in your search, exclude entries that are already tagged and also limit the results to some amount X.

Send the emails and delay invoke another workflow. Search again and send another X.

Your search amount could be dynamic based on current load, current form submission load (assuming your Form's process archives something to the repository).

Let's say your delay is every Y minutes until you run out of entries to notify on. Each new workflow runs a search for new submissions to get a count, the search count maximum, X, is then the inverse of submissions. IE: If only 10 submissions have come in within the last 5 minutes the server is not busy and you can send out 90 more emails. As the count of submissions received in the Y interval increases, less and less emails go out in that interval. As the count of submissions received decreases, more emails go out.