Records with no Postal Address

You say that the records with no address have a Street1 of "***No Address***", which suggests that they actually do have a row in T_ADDRESS, which should make it easy to update and isolate these records, assuming you or someone at your org has SQL access to your data.

10019 is a real Zip, and you've seen why using a real zip for fake addresses is bad. I would recommend something like "99999", which is what we use, and which is our Default Postal_Code in T_DEFAULTS.

We also set all such addresses to geo_area = 0 ("Bad Zips").

In my opinion, using the "require address" setting and then allowing addresses to be created that signify no address is the same as not using the "require address" setting. You didn't mention whether you had that set specifically, but at our org we had the same thing going on and I eventually decided to allow constituents to be created with name only, since that was the reality of our business needs.

This results in better-quality data, and if there is a need to enforce policies on gathering data this should be done at the web application or phone agent training level, and not the database level (the T_DEFAULTS setting doesn't really affect the database schema, but you know what I mean).

That makes sense to me, but it breaks TNEW, at the very least.  

We're on TNEW... is this broken in a new and exciting way that I didn't know about? :-) TNEW requires an address, but as far as I know it doesn't require that the T_DEFAULTS setting be set to require an address. That's what I meant about enforcement on the application level.

There was a problem with buying a ticket with a prexisting account without  a primary address.  However, that might have only been triggered if it had an inactive address but no active addresses.  Can't remember.

Oooh, good to know. I'll definitely give that a test; thanks!