My impression is most databases are designed fairly haphazardly, and while tables may have fields added, the entity relationship diagram stays pretty static. My rationale is as follows:
1 - A database schema requires quite a bit of thought and up-front design, which we're loathe to do in this agile world.
2 - Schema migrations are hard and scary, so we avoid doing them
I'd guess that (2) is more important than (1) here. Or, at least, it seems anecdotally right to me that programmers are very hesitant to do migrations.
As for (1), you must be right that a disconnect between a design and eventual use is important here, but I'd have said that the more central cause is just that systems change and that their eventual use is very hard to predict. I need to think more about your conjecture that there's a misfit between programming practice and what's necessary for database work; I like the idea that we're habituated to implement something very basic up front, and that this habit intersects particularly badly with database work (that is, it causes problems that aren't nearly as bad with non-database parts of computer systems).
1 - A database schema requires quite a bit of thought and up-front design, which we're loathe to do in this agile world.
2 - Schema migrations are hard and scary, so we avoid doing them