Question is "how much" design for the future is necessary today. The basic rule of thumb that I follow is to ensure that necessary means of abstraction have been applied and are in place today so that tomorrow we can extend without reworking all the parts.
I'd rephrase rule 17 as "Don't paint yourself into a corner.". It's easy to waste time overgeneralizing a program before you have a clear idea how it will actually be used. The emphasis on prototyping also keeps this in check, though.
It's been my experience that "future proof" code tends to be filled with this stuff, and that the cost of all this chaff is vastly higher than the authors think it is when they write it.
I think perhaps it means more like "don't make your Epoch 32bits long, it'll soon be 2038" oh