The central point is that if your project is successful, it will need to evolve. You won't have time to throw it away and create a revolutionary new version. If you are lucky, you may have a chance to throw away the parts that really suck and replace those. Design for evolutionary change: design for the ability to extend and replace parts of the system without having to redo the whole thing. Design for a system with evolutionary baggage because that's what you will get. As with most design philosophies, this involves striking a balance. There are several directions in which people seem to go too far.
The first is to over-design. It wastes energy to plan out capabilities of some subsystem that you don't need today only to find that by the time you do need them, the requirements are so different that your design (and possibly implementation) are wasted. In the most pathological case you can potentially spend so much energy designing that an otherwise successful product never gets off the ground. You can take things too far in another direction: deferring decisions too long because you are uncertain about the future so that your system balloons with complexity to support all the potential paths. Differing decisions that are cheap to defer is great. It's worth trying to find ways to make decisions that will reduce complexity. The final common failure is to under design: we won't need extensibility today and it can't possibly be harder to add later, can it?