I usually explain it this way to the PHBs - code is the walls and roof, the database is the foundation.
Moving the walls and changing the roof can be done. Changing the foundation around requires a lot of digging and rebuilding the walls and roof.
What inexperienced developers (and college professors) say is "over engineering" is what experienced developers call "future proofing". Despite what the spec says you know what will probably change during the ALM or where the performance problems will occur so you want to get your table structure right to start with.
Rolling out update scripts to customer servers is a non-trivial project and each of the customers' DBAs are all over you wanting to the triple check it all. Some extra columns and tables aren't so bad after all.