The host header is the URL on which the web application will respond. If you specify a host header during the creation of a web application, you'll notice that a binding with the same URL is added in IIS Manager as well. This allows IIS (and thus SharePoint) to respond with the correct content when you request a specific URL.
The web application host header and the IIS binding must match for SharePoint to serve content. Multiple host headers (and IIS bindings) are allowed; you can use alternate access mappings to specify additional URLs on which the same content will be served. If you add alternate access mappings after the default zone created during the web application creation, you must manually add the IIS bindings however!
If you create a web application without a host header, SharePoint will serve content for that web application if the URL specified doesn't match the host headers of any of the other web applications hosted by the server. This is used typically for SharePoint 2013 for app support as the URLs are a prefix, followed by a GUID, followed by your app domain, therefore different for every app. SharePoint uses this no-host-header 9app listener) web application to listen for traffic that doesn't match any of the web application host headers and then routes it accordingly to the appropriate app.
You can only have a single web application with no host header on a particular port per farm (otherwise with two, SharePoint wouldn't know where to route the traffic).