Nice article. I agree that it makes sense to put as much of it into one table as you can. We use a similar system, but we added a couple variations. One was that we wanted to support the idea of scope - some lists like state and country are global (sorry, to make this make sense, each of our customers has its own db) so we don't want to have to add a row to every db if a new one comes along. At the same time, a particular customer may well say that they only do business in North America, so we create a db scoped list just containing the values they use. Then there are the exceptions - so we can put values into a "campaign" scoped list. We control this through another lookup table that tells us what proc to execute and what params to pass to it - our app config program sets all that up. It's worked out fairly well. Our other goal in building it was emphasize our ability to cache the lists client side and only update if changed.
Saw a couple notes about using strings and numbers - anyone looked at using sql_variant instead?
Andy