I read the article thinking that I might find a technique that could make my database designs either easier, faster, or better in SOME way, but I don't believe this technique accomplishes any of this.
I wrote an article a while back that had hints of this concept, but had a more structured base and had a definitive use. http://www.sqlservercentral.com/columnists/dsumlin/lookupstrategy.asp
The main problem I see with this concept is that there is no control over which values exist for a particular domain. (I'm sure there's a complicated technical term for this, so I'll explain).
The technique that he presents appears to be a good place to store lookup type values, OR values that may be used in other places so as to eliminate redundancy. The problem with this is that there is NO way to determine boundaries of that data.
For example: Let's say you have a Customer table with a CustomerType field in it. The allowable values are (Wholesale, Retail, Distributor). You then have another table called Sales with a ReferredBy field. The allowable values are (Internet, Friend, Distributor, etc)
How do you (from an application standpoint) limit the values that can be put into a particular field and how do you display lists of allowable values for instance? (e.g. A drop down list of Customer Types?) Do you have to do a DISTINCT/GROUP BY of the Customer table each and every time? And how would you inactivate a selection for one domain, while allowing it to be valid for another domain. (e.g. Distributor might no longer be a valid value for CustomerType, but be valid for ReferredBy)
The only thing that I see that this concept does besides being confusing to most developers, making the database actually more complicated, and making changes to data more difficult is save some data space. And the space saved isn't worth it in my opinion.