You have a very large number of entry fields with a large number of similar attributes, and you want to simplify your application code.

This is what configuration files coupled with useful abstractions are for. This is not what a database is for.

You expect the allowable values for some of the fields to frequently change over time, and you'd like to avoid multiple trivial releases of your code.

Changing the allowable value of a field is NOT a trivial release. If you allow a value that goes over an edge case, then you have introduced dirty data. Dirty data is almost always impossible to get out.

You need to be able to re-configure your application on the fly in a distributed environment.

This is the ONLY relatively sane reason to put application logic into a database. And, there are much better ways of accomplishing the same thing. The only thing a database brings to the table is the centralization. Centralized datastores aren't necessarily a full-on RDBMS. For example, a simple DBM::Deep or BDB file on a NAS would be perfectly fine for things like this.

And, I've saved the best for last ...

Updating your code in production is fraught with red tape; in some corporate environments, database changes can often sneak under the wire, avoiding onerous (but unsophisticated) bureaucratic constraints.

Allow me to rephrase: "Because my company actually respects change control, I will exploit a loophole in order to avoid actually managing my changes. Instead, I will unleash changes unto prod in a lone-cowboy fashion."

Change control exists for a reason. Often, it's because you do NOT understand the ramifications of your changes. Furthermore, even if your bureaucracy should be avoided, you are breaking your application design. Assuming that this is a good plan, it is a consequence and not a reason. It's like saying "Eating a bowl of sugar is good for my health because it's better than eating a bowl of lard."