Specifically in this case, he is creating a set of constant pool entries in the class, which are indexed from 1..n rather than 0..n-1, so if you have a constant pool that needs to hold 10 items, you have to declare 11 in the count of the constant pool.
One possible reason for this is because most of the constant pool entries work by indexing in to itself recursively (so you can do pool[pool[thing].value]) there’s no way of using a null or missing value.
So when you have java.lang.Object, the super class field contains 0 to indicate that there is no superclass, and if 0 were a valid index into this pool structure then this approach wouldn’t work.
Of course whatever the reason, we have been stuck with this implementational quirk since the first Java release, and it would be a backwards incompatible change if it were different, just like the fact that double and long occupy two slots on the stack - because that was a quick way of allowing 64 bit values on a 32 bit stack, and even though most JVMs now have a 64 bit stack we still “waste” a slot entry each time.
So the toast “one more for the Java gnome” is the extra space you have to allocate for the 0th entry of the constant pool in Java class files.