Normalising shared entities and applying constraints
The motivation for piling every kind of address into a single table is usually a misinterpretation and misapplication of the notion of code reuse.  

People can make the mistake of assuming that because you have two entities with some common set of attributes, that those attributes belong in their own table.  Sometimes entities have similar or identical columns coincidentally.  One wouldn't create a table for every NAME or DESCRIPTION or EFFECTIVE_DATE in your database, at least I hope one wouldn't be tempted to do this.

Some people mistakenly refer to all instances of removing columns out to their own table as normalisation.  Normalisation involves removing columns to their own tables, but not every instance of removing columns in this way is actually normalisation.  Normalisation prescribes very specific reasons for removing columns from a table.  If none of these reasons are applicable then you aren't normalising you're just making things complicated.

You have two correct ways of thinking about this:  Either your addresses all belong in one pile because you have an entity super-type that incorporates all of the common features of several entity subtypes, including addresses, - or - your addresses belong in separate piles (tables) according to each kind of thing that has an address and you write your procedural code against an IAddress interface which is implemented for each address table.

If you actually have an entity super-type, say LEGAL_ENTITY which has subtypes like CUSTOMER, VENDOR, EMPLOYEE and so forth, then having an ADDRESS table that is a child of LEGAL_ENTITY is a legitimate approach.  It may even be a valuable approach if there is significant overlap between your customers, vendors, employees (or whatever you're tracking) because you can change addresses once instead of in multiple locations when a legal entity moves.  On the other hand, if you don't have such a super-type, then you are going to face the problems pointed out by Richard Tallent.

If you keep your addresses in different tables according to what type of entity owns the address, then you can still achieve code reuse, assuming the language you are using supports interfaces.

As an aside: tvCa pointed out in a comment that addresses may be stored as columns rather than as rows in a separate table.  That will depend largely on how many addresses you need for each entity.  If you are tracking two addresses (physical, mailing) or if you are storing address history then go with an address table.  If you only store one address per addressee, then a separate table is likely overkill.