I would separate the CI and CD contexts, as the periodicity in one of them is rather loosely coupled to the periodicity in the other one.
That's primarily because CI attempts to produce versions of software available for delivery/distribution, see How does continuous integration relate to continuous delivery / deployment?
But not all CI executions are successful. CD periodicity will, at best, be equal to the CI one, but typically it will be lower.
In CI the periodicity is tightly coupled to the desired development velocity (and maybe branch stability) and can be driven by different project-specific requirements. Here are just some examples of CI execution patterns, there could be others:
launched for every changeset commit - the recommended one, as it offers the shortest time to identify a changeset causing a regression, see Build on each commit - Continuous delivery. Costs vary with the commit rates.
N (fixed number of) commits - trade culprit identification performance of #1 for slightly lower costs (overall fewer executions)
T (fixed) time interval
- fixed costs due to predictive amount of executions: no cost hikes for commit activity peaks, a day with twice the number of commits than another will still cost the same
- culprit identification performance drops vs #1 if multiple changesets are committed within
- consecutive executions without any changeset committed in between offer measurements of the verification process reliability - different results in such executions could indicate unreliable verifications
launched whenever resources for execution are available - if that's where the bottleneck of the process lies. Any of the above categories can appear depending on the pattern of commits relative to the intervals between executions. This maximizes the verification resources ROI.
launched with one pattern during working hours and a different pattern overnight - to balance computing resources utilisation, for example.
Another possible reason for periodicity mismatch between CI and CD is the variability in the duration of the CI executions. Caused, for example, by that prohibited build schedule policy you mentioned (see also How to implement a frozen test environment?) Or by builds executed on classes of servers with significantly different performance, thus lasting different amounts of time.
Even for a successful CI execution in which the produced software version qualifies and is available for deployment it doesn't necessarily mean it will also be immediately deployed (or even deployed at all). There can be other criteria or policies preventing it (business reasons, for example).