Hi AaronBertrand,
In reference to I/O being expensive. Using the proposed logic of having to join back to the table to find the successor record, ir going to cost you allot more than the storage of the end date on the record.
With the premise of rejoining we would need to reparse the table index (which on a large table is still large) to find the appropriate record and then read the table to get the record. Under the best of circumstances this would be at least 3 additional I/O's that otherwise would not be required.
This is a big reason why compression of tables can have a big impact on the DW performance. It reduces the amount of I/O, but at the cost of CPU cycles to compress and uncompress data.