The bottom line is that Designing for Change is a risk-reduction practice. If the system is stable, it doesn't produce immediate schedule reductions, but it helps to prevent the massive schedule slips that can occur when unanticipated changes cause widespread ripple effects through the design and code.