I'm far too rusty to sit down and calculate time complexities myself

Big-O notation only really cares about asymptotic complexity, so you basically need to treat numbers as if they were 0, 1, or infinity. This is fine for stages and sets since we have so many of them we can kinda pretend they are infinite and still get something sorta useful. But with the number of matches its a little weird, treating them as 1 hides repeated costs that are actually a big deal, but treating them as infinite hides once per set costs completely.

In an attempt to deal with this and still calculate the time complexities I've split up complexities for picking the 1st stage, and complexities for picking stage 2 and onward. This is probably more useful as an example of why you should only use Big-O notation when your algorithm runs on really large inputs, but it was kinda fun

Methods for picking stage 1 ordered by Big-O time complexity on N the number of stages:
Ordered lists compared by TO ahead of time: O(0)

- stage selection is already done. The setup time before hand is pretty huge though.

Random: O(1)

- real fast! if only it was fair x)

Random with bans (e.g. FLiPS): O(N)

- linear setup for the first stage.

Static ordered lists compared before each set: O(N)

- If the lists are made before hand their creation time doesn't affect the time complexity here. The algorithm for selecting the stage has linear complexity in the worst case scenario.

Striking: O(N)

- plain old striking is also linear.

Ordered lists that can change between sets: O(N log(N))

- letting the players re-sort their lists between sets could take a while in the worst case scenario, although irl it would probably only be a few minor changes and be during player downtime anyways.

Methods for picking stage 2 and on ordered by Big-O time complexity on N the number of stages:
Ordered lists for all stages at once: O(0)

- if all the stages are picked at once using an ordered list, stage selection is already done at this point.

Random: O(1)

- still real fast! still not fair!

Random with bans: O(1)

- makes setup take O(N) time, but just as fast as pure random afterwards, and somewhat more fair.

pXp1: O(1)

- Picking a constant number of stages and then picking one stage off that list is constant time.

pXp2p1: O(1)

- same as pXp1, just with another constant time step.

Counter-picking with bans per set (e.g. FLiPS): O(1)

- makes setup take O(N) time, but has constant time for every match afterwards.

Counter-picking with bans per match: O(N)

- this would technically be O(1) if you only ban a constant number of stages no mater how long the stage list is, but to be actually fair the number of bans should grow linearly with the number of stages.

Ordered lists that can change between matches: O(N log(N))

- letting players change ordered lists between matches would be a very bad idea xD

EDIT: terminology fixes