This question has been converted to Community Wiki and wiki locked
because it is an example of a question that seeks a list of answers
and appears to be popular enough to protect it from closure. It
should be treated as a special case and should not be viewed as the
type of question that is encouraged on this, or any Stack Exchange
site, but if you wish to contribute more content to it then feel free
to do so by editing this answer.
For non-GIS background devs creating single-function mapping apps - I'd probably recommend Leaflet (now supported by MapBox). Easy to use and small. More functionality relies on plugins of varying quality and support.
GIS online type application - use OpenLayers3 - has the full suite of data sources, controls etc. in a single library. It can also be used for simple mapping apps, so if you have a mix then I'd use this for everything.
Google still has the library/data combination (e.g. StreetView is not available anywhere else).
Esri has GUI web app builders, and as noted below, why complicate things if you already use their stack.
Commercial APIs (Google, Bing, Yahoo)
Using any commercial API leaves you at the mercy of whatever changes the provider makes to the API or Terms of Service. What happens for example if suddenly your local government portal that uses Google Maps suddenly has adverts popping up all over it? Want to reuse your JavaScript Google Maps code for an Intranet site? You'll find yourself having to pay the $10,000 licencing fee.
Microsoft often have more defined and fixed terms for their services (if paying) so there may be less of a risk here.
The recent backlash against Twitter is a good example of developers having an API that changed beneath them. If you aren't paying for a service then you (or your system) are the one being sold.
Google started charging for use of their maps from October 2011.
Esri
As others have mentioned if you are using an Esri stack then the ArcGIS API for JavaScript will no doubt work well on top of it. Coming from a GIS background Esri have probably thought more about traditional GIS tasks and features than the "neo-geography" web-giants (though this is just an opinion/feeling).
OpenLayers has built in support for ArcGIS REST layers, and if you are looking to reuse your code for non-ESRI based websites then again an open API serves you best.
Use OpenLayers...
I can't really think why developers would use an API other than OpenLayers. Open Source projects lead to related Open Source projects so there are a wealth of reusable components out there such as the GeoExt library, MapQuery, and GeoPrisma.
I'll just add that just because a project is Open Source does not automatically make it better than commercial equivalents - but the OpenLayers API matches the commercial competition in this case, and the ability to see how the source works, the unit tests, the build scripts etc. mean that you can easily build new features on top of it.
There has been some recent criticism of OpenLayers, mainly related to complexity, styling, and size. There have been counter-arguments made to these here and here by Christopher Schmidt one of the lead developers of OpenLayers.
It is worth noting that if you need a simple Open Source mapping API then take a look at Cloudmade's Leaflet.
The comment smaller, faster, newer, and more straightforward can also be read as less features and less tested.
Scan the API documentation for Leaflet and OpenLayers. The latter includes items such as WFS layers, editing tools, and SLD support. It has also been tested in many different environments, and works in IE6 (allowing government and local authority users).
For simpler display of spatial data Leaflet looks ideal, and easier to get started. However I'll be sticking with OpenLayers for more feature-rich GIS applications.
Caveats
One possible downside is often new innovations are seen first in commercial providers' systems - however these nearly always filter through to OpenLayers in time.
Finally I'm sure there are certain scenarios where other APIs are more suitable - on custom hardware, to fit in with an organisations other IT systems, or if you already know an API inside-out and can get a system developed in half the time.
All the APIs you mentioned are capable of producing great online mapping systems, but your choice should also fit in with you or your company's future development needs.
Best Answer
From what I've gathered you've got a list of zip codes and their respective coverage status.
Get the Shapefile
First off you will need to source something called a 'shapefile' which defines the boundaries of the zip codes that you have. A simple google search brings up the following page: http://www.census.gov/geo/www/cob/z52000.html (...assuming you're American)
Note that if your analysis spans multiple states, it would be more convenient to continue searching for a shapefile which spans the continental USA. Likewise, you could search for a more recent dataset, but my guess is that Zip boundaries don't change considerably enough to change your results.
Get the Software
Once you've got the shapefile, note a shapefile is actually many files (.shp, .dbf, .shx ...), you'll need an application to open it in. QuantumGIS (QGIS) is the most common FOSS alternative to the commercial packages. In addition, this site has tracklog of well answered questions given the handful of advanced users who frequent here. New users are reccomended to download the latest version here.
Checklist
At this point, it's assumed you have the following:
Given you've only obtained one spatial file, there's little point in getting into the details of Coordinate Systems, and Projections. You should be aware, however, that these things exist and are the root cause of many problems between multiple datasets.
What to Do?
What you need to do at this point is associate the two sources of data that you have. In spatial/database terms this is simply called a 'join'. The image below provides a working example of rainfall per county.
KEY POINT HERE: Ultimately you will want to join every record in your shapefile to every record in your coverage data. The link between the two files will be the zip code field in each data source.
Do The Work
Have a look at the following tutorial on joining data in QGIS which links data at a state level:
http://mapbox.com/tilemill/docs/guides/joining-data/
(I'm happy to fill in the gaps here if you have issues, but I don't want to reinvent the wheel considering the depth of your question)
Symbology
Once you've created a join you need to give it context by applying symbology. I would imagine that 'good' coverage areas will be green, while 'bad' coverage areas would be 'red'.
Again, have a look at this tutorial for vector symbology in QGIS.
Discussion
As requested, I believe I provided enough information above to get you started. Please have a look at the QGIS manual if you have further questions about symbology, output and printing. For anything else you're stuck on, gis.se is here for your questions.
Links
If my information isn't enough for you to get going, by all means please comment. Otherwise, here are some other sources of general instruction for the software.
QGIS User Guide
Chapter 2 - Managing your data
Joining Data from an ESRI perspective