In an ideal world...
... every database would be designed right before it's deployed, same as every home you move into should fit your needs perfectly before you drag your mattress across the threshold.
But humans are quicksilver. We're a fortunate kind of animal that can change its mind when the situation changes. Stands to reason that when someone (or more typically, some new organization) takes over the running of a bunch of databases, the design of them will seldom be perfectly tuned to the needs of the new arrivals.
Whether you call it agile, extreme, pragmatic or simply living in the real world, it's plain useful to be able simply, accurately and reliably to refactor a database. It means you can thereby renew or extend its service lifespan rather than start all over from scratch. It means saving money on unnecessary greenfield development projects every time the team-lead changes. It also means saving a lot of time and focusing on what matters.
And you have to say it's also the way things are moving in the industry. Microsoft have dipped a toe in the water with a simple object rename refactoring in their team suite (http://msdn2.microsoft.com/en-gb/teamsystem/default.aspx). And Red Gate have gone further with a dedicated database refactoring tool SQL Refactor (http://www.red-gate.com/products/SQL_Refactor) at a price that makes refactoring even more sensible.
Personally I think the pragmatic approach to evolutionary database design is really welcome. It's a return to the commonsense attitude of the generation (now in their 80s) who said "If it's broke, let's fix it." Unfortunately it was the boomer generation who swapped this wisdom for, "If it's broke, let's replace it."