Doesn't this overly complicate what should be a simple design.

If you want to store address_types then create a table called address_types and store them in there. If you need a lookup table for phone number types then create a table called phone_types and store them in there. If you start mixing 'types' of things in the same table then you have changed the table from being an entity of one thing to being an entity of many things and make a joke of what a foreign key constraint is supposed to be used for.

What happens in future when you want to add more detailed information for an adress type? You cannot simply add a column and insert the data because your table does not only contain address_types. On top of that if you did decide to create a new address_type table then making all the modifications to your original design would be time consuming and complicated.

All foreign key constraints used in a mixed lookup table can never be relied upon to be 100% accurate. You can keep adding check constraints in every table that uses your one lookup table but this once again complicates what should be simple.

I prefer the design of many different lookup tables each unique and unambiguous in their purpose. It allows for foreign key constraint checks to be 100% accurate (what could be more important than accurate data) while having the flexibility to expand the tables columns as you see fit.

If there is a concern that the number of lookup tables will exponentially grow and you wont know where anything is....I guess that is a different topic.