@Jules's link to the incrementer details offers an unsatisfying explanation:
When the Z-80 was introduced, 16K memory chips were popular. Since
they held 2^14 bits, they had 7 row address bits and 7 column address
bits. Thus, a 7 bit refresh value matched their need. Unfortunately,
this rapidly became obsolete with the introduction of 64K memory chips
that required 8 refresh bits.
That explanation suggests no reason why the designers couldn't have chosen 8 bits, with an eye to future memory devices.
I think the real reason lies elsewhere in that description.
Bits 7 through 11 are computed using the carry lookahead value,
allowing them to be computed without waiting on the low-order bits. In
parallel, the carry/borrow out of these bits is computed by the large
NOR gate in the middle, and used to compute bits 12 through 14. The
last carry lookahead value is computed at the left and used to compute
bit 15. Note that the number of carry blocks decreases as the number
of carry lookahead gates increases. For example, output 6 depends on
three inc/dec blocks and no carry lookahead gates, while output 14
depends on one inc/dec block and two carry lookahead gates. If the
inc/dec blocks and carry lookahead gates require approximately the
same time, then the output bits will be ready at approximately the
i.e. The splits in the circuit structure were designed to meet overall timing constraints on the 16-bit incrementer, without regard for any secondary function it may be used for. As it turned out, one of those splits was between bits 6 and 7.
One unexpected feature of the Z-80's incrementer is that it can pass
the value through unchanged. If the carry-in to the
incrementer/decrementer is set to 0, no action will take place. This
seems pointless, but it actually useful since it allows a 16-bit value
to be latched and then read back unchanged.
Furthermore, if the carry-in to bit 7 of the incrementer is set to 0 - via the 'refresh' input to the NOR gate - then the upper 9 bits of the incrementer will not increment, but will preserve their input values.
The program counter and refresh register are separated from the rest
of the registers and coupled closely to the incrementer. This allows
the incrementer to be used in parallel with the rest of the Z-80. In
particular, for each instruction fetch, the program counter (PC) is
written to the address bus and incremented. Then the refresh address
is written to the address bus for the refresh cycle, and the R
register is incremented. (Note that the interrupt vector register I is
in the same register pair as the R register. This explains why the I
value is also written to the address bus during refresh.)
i.e. The I and R registers are updated through the incrementer as a 16-bit pair, just like the PC - but in this case the upper 9 bits are not incremented, and so I and bit 7 of R are actually reloaded with the same value. There's no separate load control for the two halves of the pair, at least as far as the incrementer is concerned.
(EDITED TO ADD: That's actually quite an assumption on my part, especially considering the separate I & R load capability I mention below. But I think that even if R can be loaded from the incrementer independently of I, the argument still applies to bit 7 of R.)
(Note that I and R can be individually transferred to and from A, but this is a distinct function from the refresh-cycle increment.)
So: While it would seem natural for the refresh counter to use 8 bits, the internal structure of the 16-bit incrementer (adopted to meet its timing requirements) was such that a 7-bit counter function is what was available - and this was sufficient for the prevailing memory technology of the time.