For the most part it's probably that they kept things flexible that aren't strictly necessary, but it simplified their development process of the silicon.
So when they're done with the silicon, and routed all the traces, and so on, they can run their magic tool that measures delays and things like that, and then calculate the best performing set of values, and write them into the document.
It also allows them to dial back some of the values should they figure out that there are problems. I fully expect these numbers to change a couple of times between them finalizing their silicon and releasing it (and the reference code and documentation) to the public. Now consider how much trouble it would be, even for Intel and their world famous fabrication process, to create new silicon for each of those changes.
Take the tables in i945's raminit (http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=sr...).
From the shape of these values, they're probably some delay configuration for the different types of DDR2 pins (dq, ctl, clk) going from somewhere inside the silicon out to the pin of the package, but I doubt that the documentation actually provided any explanation for them.
Of course, one of these registers could mean 'change all calculations in a way that the electromagnetic field contains the private key'. But they need a better way to enable that function than in firmware, where it's done for everyone.
In the end, I'm fine with such magic values in magic registers, as long as they make some sense (right register block for the current task instead of messing with the audio codec while initializing usb) and are unconditional (that is, no if (user_is_evil()) write_enable_tempest_register(); ).
If there are no unexplained conditionals, any backdoor would have to apply to every user - in which case they could just enable it unconditionally in silicon.