Salesforce Flow Limitations – Loop vs Batch Records

You can't call Database.executeBatch that many times, so you'd end up having to schedule 12 copies of your class (or 12 different classes) for your scheduleable methods, on top of the 12 batch classes. Instead, perhaps you could make your batch size 1, and pass in the calendar month for each:

public class BuildQuotas implements Database.Batchable<Integer>, Schedulable {
  public void execute(ScheduableContext context) {
    Database.executeBatch(this, 1); // One month per execute
  }
  public Integer[] start(Database.BatchableContext context) {
    return new Integer[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 };
  }
  public void execute(Database.BatchableContext context, Integer[] scope) {
    Integer calendarMonth = scope[0];
    // Do your work here
  }
  public void finish(Database.BatchableContext context) {
  }
}

Using a Wait (now called Pause) element does preserve the Flow's state, including all of its variables and the field values of queried sObjects, across the boundary into a new transaction. As expected, limits are reset across the transaction boundary.

This strategy is more or less explicitly endorsed by the documentation:

A transaction ends as soon as a flow interview begins to wait for an event. When the flow interview resumes, a new transaction begins. Everything after the Wait element is executed as part of a batch transaction that includes other resumed interviews. [...]

Consider using multiple Wait elements so that the DML operations and SOQL queries are performed in multiple transactions.

But you need to also be aware that, like Workflow Rule Timed Actions, Flow Interviews are batched when resumed, and this can cause limits consumption to not look like what you expect:

Interviews aren’t resumed independently. They’re grouped into a single batch that starts resuming within one hour after the first interview enters the batch. Actions that execute as a result of the grouped interviews are also executed in that transaction. [...] This behavior can cause you to exceed your Apex governor limits if the resumed interview executes DML operations or SOQL queries ...

Simple Demonstration

Here's a demonstration. I put together a simple Flow thus:

It's an autolaunched Flow. It queries a single Account record (at random) and stores it in an sObject variable. It calls an Apex Invocable Method (below) to check Limits.getQueries() and stores the result in a Number variable. Then, it Waits for a Platform Event.

When the event is fired and the Flow resumes, it re-checks the SOQL limit and stores that value too. Finally, it sends an email with both SOQL values and a field value from the original queried Account back to me so I can look at the results.

Here's the Invocable Apex:

public class InvocableSOQLLimit {    
    @InvocableMethod(label='Check SOQL Limit')
    public static List<Integer> checkSOQLLimit() {
        return new List<Integer>{Limits.getQueries()};
    }
}

And here's what I get in my email afterwards:

Account Name: ACME Industries
SOQL Before: 1 
SOQL After: 0

This shows that the transaction limits were reset (we burned 1 SOQL on the original query, and none after the Wait element), but we preserved the original Account field values queries before the Wait. (They may now, of course, be stale).

Of course, you must contrive some way to have your Flow restarted. I just used a sample Platform Event, Test__e, that I fired via Anonymous Apex:

Test__e event = new Test__e();
EventBus.publish(event);

But that's not going to facilitate a production Flow. Instead, you can configure your Wait element to go off "more or less now", zero hours after the current date and time:

As far as I can tell, the docs (and two) are not explicit on the exact semantics of this time trigger when it's in the past, but it seems to work like Process Builder (as one would expect, since they're the same under the hood and the rest of the mechanics are similar): setting it to zero results in a resume within a few minutes, subject to server load.