Once a CSP has been correctly configured such that no violations occur in normal circumstances, it seems desirable to place some restrictions on the number of violations which will be logged (by the default Drupal handler) should violations start to occur.
Picking sensible default values for these limits is a bit tricky...
If the CSP is correct and there are violations, then the number of reports will depend on the violation(s) and of course the popularity of the page(s) in which they occur.
If the CSP is incorrect (or becomes incorrect with subsequent changes to the site), then there may be many unintentional violations. (e.g. if triggered by a new global page element on a popular site.)
In either case I don't think that SecKit can predict what those numbers might actually look like for any given site, so my broad inclination is to base restrictions on "what's liable to cause performance problems". Which of course is also incredibly variable, but is probably still a better basis for extracting some practical baseline figures from.
The numbers I've pulled out of the air are:
Maximum CSP reports by all users: 1000 in a 3600 second (1 hr) window
Maximum CSP reports by a single user: 100 in a 900 second (15 min) window
Maximum report size: 4096 bytes (which should be excessive for a real report).
These are high enough that they could still cause some undesirable effects (dblog's default row limit is 1000 for starters), but I don't want to try to detect and adjust figures based on whether any particular watchdog module is enabled and how it's configured.
(Any recommendations are welcomed.)
Each of those limits is configurable, and they can also be disabled entirely, but for sites with existing CSPs, the limits will be enforced by default.
People in the initial stages of configuring a CSP would almost immediately blow past those per-user limits, however, which would mean that useful reports for establishing a CSP would be lost; so hook_install overrides this default in order to allow unlimited reporting, so that we do not cause problems for users who newly install SecKit. Similarly if SecKit is already installed, but the CSP configuration was in its default state, we do the same thing (in an update hook) so that if/when they start working on a CSP, they will start out with unlimited reporting.
n.b. I don't feel there are any sensible values which would cater both for initial CSP development and for subsequent flooding of a stable CSP.