I guess the answer is: it depends. Do you want to restrict the user to specific values (avoiding typos) or choose from a list of previously entered values. Actually in both of those situations, the drop down list function works. It depends on if you are using "custom values" or "values from field". If using values from field, that field can be from the same table or another table. The amount of control you want is up to you.
As Mark said: you can always use field values as value lists for dropdowns and popups.
My personal take is: if the values are data in itself or need their own attributes, I use a table. Also, I find it easier to work with fixed numerical keys – especially when defining filters for portals or relationships – where you can also change or correct the value names without impacting the functionality, since it is based on the keys.
A simple example: if you have project stati (statusses) and want to be able to sort projects not only alphabetically by status name, but also in a chronological order or order of priority, a Status table lets you add these attributes and use them in reports, filters, relationships etc. A hard-coded value list wouldn't give you that kind of flexibility and require clumsy workarounds.