For the biggest part I tend to agree with your statement.
I think it is a good practice to separate the enumerations within an application as opposed to throwing them on a big pile. However the article only mentions one possible solution. One of the problems with this approach arise when the descriptive values of these enumerations are used in the GUI, reporting, etc; it is very language-dependant, thus severely crippling any potential of global use.
Another situation is when the enumeration is a “behavioural” one; a finite state machine e.g. the acceptance to a meeting in outlook, defined as “Accept”, “Tentative” and “Decline”. It is very unlikely that we need to change this enumeration on the fly without the need to change any business rules / workflows depending on it. In such cases I prefer to a custom data type constrained to the proper values. The loss of meaning can be compensated by using textual representations instead of integer values. The gain implies less joins, less tables, less complex diagrams, etc.
Cornelius van Berkel