It's built on open data sets, including OpenStreetMap and OpenAddresses. In populated areas coverage is really good. Thanks to OpenAddresses, several countries have full address coverage. You can see the coverage map on openaddresses.io. New data gets added as these open data sources grow.
OpenAddresses is a directory of publicly available address lists provided by government agencies at various levels. It's designed to be bulk imported by machine.
Many addresses exist in OSM. But there's a preference from the OSM community that data be entered by users familiar with their areas, that they can verify on the ground. Imports have happened in OSM, such as the controversial TIGER import in the US years ago, and the NYC building dataset more recently. But these require a lot of effort and attention to manage well.
It's not out of the question, however there are many obstacles to overcome, such as licensing, validation, and the fact that the OSM community generally insists on manually entered data.
I've heard many folks push for consolidation of various open data projects, so they aren't "competing" for contributions. However the reality is that they are currently very different and each serves to bridge a very specific gap.
In the meantime, it makes a lot of sense for projects relying on open data to pull all of these sources in, as Mapzen Search is doing, to ensure the best possible coverage.
That's the wrong question - the question is wether the sources from OpenAddresses can be merged into OSM. I know of at least Denmark that there was some address import.
Mapzen uses only open data, in particular OpenStreetMap and OpenAddresses (http://openaddresses.io/). This means anyone can improve the results and always have access to the data if something's missing.
Nominatim, which I worked with at MapQuest Open when it launched, is a great geocoder for purely OSM data. We built Pelias (https://github.com/pelias) at Mapzen because Nominatim is not built to handle autocomplete. We also wanted to start with a fulltext search engine -- Elasticsearch in this case -- instead of Postgres with search logic on top of it. We also wanted to search other open datasets like the fast-growing OpenAddresses.
They're great and we have many friends at both companies. Our main goal is to get map data and software into the open so others working toward that goal are not really competitors.
If there's overlap, I don't see why that's a bad thing. The geo industry has had the problem of too few options for a while. More options are a good thing.