Data bytes indeed must have a value between 0 and 127.

That description is wrong, and should have been zero-based.

In my opinion, Clemens is right when says that MIDI data numbers are always zero-based. I don't agree with him when says that the specification is wrong.

Let me explain: you know about the MIDI channel numbers. There are 16 MIDI channels, numbered from 1 to 16. All musical instruments display the same numbers for the MIDI channels, like the instruments' documentation, and like the specification does. But the channel number is encoded in the four less significative bits of the status byte (of the channel message events) as a number from 0 to 15.

All MIDI data numbers are zero-based. But as a general rule, when the data number represents an enumeration it is documented as one-based (like channel numbers, program numbers, or bank numbers). When the data numbers represent magnitudes, they are represented zero-based, like MIDI velocity (0-127).

I want to add that I am happy with this tradition, because a long time ago musicians were considered artists, not engineers 😀

While I understand how some values, such as MIDI channels or program presets, may be referred to as one-based in user-oriented documents while the actual bytes transmitted start from zero; in this case tt is literally a placeholder for a byte in the data stream, and it is identified as having values 1 - 128 in that context.

To quote a bit more from the spec:

The message is sent as a registered parameter number controller message, followed by either a data
entry, data increment, or data decrement controller message, e.g. (with running status shown):

Bn 64 03 65 00 06 tt (data entry)
Bn 64 03 65 00 60 7F (data increment)
Bn 64 03 65 00 61 7F (data decrement)
n = basic channel number
tt = Tuning Program number (1-128)

The value n is not identified as having values 1-16 here, even though it's the MIDI channel, and from the user's perspective, that would be correct. It would not be correct here.
The value tt is identified as having values 1-128 here, and that is also not correct.

I know this error has lasted over a quarter of a century without anyone amending the document, but maybe someone could clarify it now? I hope so.

The spec is not incorrect.
The values of "tt" can only be 0-127 because "tt" is a hexidecimal number.
But the spec is not referring to the value of "tt", the spec is referring to what "tt" is used for, which is to select Program and Bank numbers, where the first number is "1", and the last number is "128".