No, it's a more fundamental problem: Zip codes are not "areas" and have no boundary.
Instead, what they are, are collections of mail delivery points. The "full" 5+4 zip code represents one mail delivery route that a postman follows to deliver mail. And the "fuller" 5+4+2 zip code has the last two digits of the street number.
So couple issues with trying to make polygons from zip codes:
1. There is no guarantee that a given zip code has a finite area. There are several zip codes that exist at a single street address. So... is that a point? Is it the footprint of the building where the mail is delivered? Maybe a hexagon with some minimal side length? Examples: Several IRS return addresses, and some large hospitals.
2. There is no guarantee that a given zip code has a contiguous polygon representation. It depends on the algorithm you use to generate polygons from address points.
3. There is no guarantee that a given zip code has a fixed geospatial representation. Example: the armed forces zip codes for delivering mail to overseas personnel on deployment. The AFPO zips represent "wherever the troops happen to be today". How do you represent that as a polygon?
This is why the USPO has long resisted publishing polygons. It doesn't make sense at the conceptual level, so there are a bunch of weird edge cases you wouldn't expect if you naively treat them as polygons.
ALSO: The census does publish zip polygons. Some of those have zero people living in them (like the hospitals and IRS locations), so you can get weird div-by-0 effects if you aren't careful.