If that configuration information has a good reason to go into a database, it should still be maintained in a file, under revision control, and then the database table should occasionally be reloaded from said file.

There are many reasons for this design choice. The key one is that sane organizations do not develop against their production database. Instead they have a separate development environment that they can work against, and then they have a release process into production. (Often this release process involves more databases, for instance you may have one devoted to QA, and another for load testing.) If you store the configuration in the database, this release process quickly becomes more complicated and risky. Furthermore the development process also runs into issues when people need to do things like change a configuration temporarily just to test something. (What if you don't change it back correctly?)

By contrast when the information is in a configuration file, under revision control, then necessary configuration changes get released in sync with the code that it is connected to. Furthermore a slew of development problems are now handled by your revision control system. You can ask, and answer, important questions such as, "Here's when we changed Y, that was after this problem started being reported, so it cannot be the cause."

This opinion is strong enough that I would rather not work with companies which make the design mistake of keeping configuration information in a database. Just as I would prefer not to work at an organization without a development environment, or which does not use revision control. (The latter two are more important than this design mistake though.)

UPDATE: s/avoid working/rather not work/ and added clarifying comment.