Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the “why”, “what” and “how” of the project to the rest of the team.
Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing. A long spec that nobody reads is worse than a short one that everyone does.