A couple of considerations here:
(1) Using established code lists (e.g. currency) makes sense. The key issues that arise here are:
Synchronisation - making sure we have the latest version of the codelist
Deprecation - handling the fact that codes can go out of use, but that we don’t want to suddenly have data that doesn’t validate because a value has disappeared from a codelist
Ideally, there would be good external sources to refer to for most codelists (e.g. currency lists), but in practice groups like ISO don’t maintain really nice free and open places to point.
The Frictionless Data project is maintaining some useful packages though as codelists, and we could consider co-maintaining codelists there for currencies, countries etc.
(2) Codelists we have to create
When these are ‘open’ lists (i.e. adding a new value doesn’t dilute or change the meaning of the other values) then the main issue is just about the amount of work required technically to maintain a list, and do the research to keep it updated and accurate.
When these are ‘closed’ lists (i.e. trying to categorise the world into a limited set of buckets, such that a new category changes the others), then there is much more work around negotiating meanings to be done - and the challenge is political more than it is technical.
I understand OCDS and IATI have tried to keep the number of lists like this they maintain to a minimum, only creating them when there is a real user need.