"When I thought of a reasonable maximum number of attachments on an email I'd probably say 64."

We should not be talking of a "reasonable" maximum at all.

Rather, the maximum should be orders of magnitude away from the "reasonable".

At this distance, any arbitrariness quickly fades into meaninglessness.

Detached from the "reasonable" usage, the maximum then becomes informed by processing cost and complexity analysis, which are more concrete.

This assumes (and likely correctly assumes, in most cases) that 'reasonable limit' and 'probable system limit' are orders of magnitude apart.

I think that may not always be true though. Especially for highly variable workloads.

How many requests per seconds does your site handle on average vs how many can it handle? What about spikes?

If your previous peak is at 10 rps and you can probably handle 20 rps, when should you start dropping connections to keep the site up?

Most systems are designed to have small margins, for cost purposes, so I imagine this sort of situation might come up quite a bit.

I would disagree, a sensible limit that cannot overwhelm the machine even if a multi threaded server is processing its maximum number of emails, should be enforced.

The correct response to a breach of this limit would be for a reply email to explain the limit and why the email was rejected.

The user then could send multiple emails with their attachments, and the system can be sized to handle e.g. 24 threads processing 64 attachments of a maximum size of e.g. 4096kb

That's how you ensure a system sized to your hardware and ensure maximum throughput for all users.

"That's how you ensure a system sized to your hardware and ensure maximum throughput for all users."

Sure, I think we are actually in agreement. That's exactly what I meant by "processing cost and complexity analysis".

It can be a random number between 64 and 10000, inclusive, the arbitrariness of it is the point: there is a bound; the (loop/size/whatever) is not unbounded.

But that's just from the 'security' perspective - if it is a low number then users are likely to hit it and complain, and for bug tracing I suspect everyone would want the number to be constant.