What kind of attack is prevented by Apache2's error code AH02032 ("Hostname provided via SNI and hostname provided via HTTP are different")?
Server Name Indication (SNI) is a TLS extension which allows a TLS client to indicate which host it is trying to reach. This is important for web servers with virtual hosts (i.e. multiple domains hosted from one box) so that they can decide which certificate to return. Normally the target virtual host is detected via the Host HTTP header, but that can't be sent before a TLS tunnel is constructed. SNI allows the TLS client to indicate the name so that the correct certificate can be served, before the underlying HTTP call is made. Another feature of most TLS servers is that SNI can be used to pick between different TLS configurations that have been configured for each virtual host.
Since you now have two indicators of which host you were trying to reach (SNI and Host header) there may be odd behaviours if you force them not to match. Now, imagine a situation where you've got a site which uses HTTPS, but also an administrative subdomain, and they're both hosted on the same server. The administrative subdomain is locked down at the SNI configuration level so that it requires a client certificate. This means that regular site usage just runs normal HTTPS, but you need a client certificate to connect to the admin subdomain.
However, if you were to make a request where the SNI points to the main domain, but the Host header points to the administrative subdomain, you can construct the TLS tunnel without the client certificate (because the main site's rules are used) but the web server may serve content as if you were connecting to the administrative subdomain. This could allow you to bypass that client certificate restriction.
What kind of vulnerability or attack vector is prevented by the error?
The attack is called "virtual host confusion" and in 2014 several CDN were found vulnerable against it. The main idea is that a mismatch between the target name in the TLS handshake ("provided via SNI") and the target name in the HTTP protocol ("provided via HTTP") can be exploited. Depending on the setup of the server it might be used to impersonate HTTPS sites owned by others which also can be used to steal session cookies etc.
For more information read the paper "Network-based Origin Confusion Attacks against HTTPS Virtual Hosting", read the information at HackerOne, see a video of how this attack helps to "use Akamai to bypass Internet censorship" or see the talk at Blackhat 2014 where this and other attacks against TLS where demonstrated.
If you have a setup in which a lightweight frontend uses SNI to dispatch requests across different HTTPS servers, the extra check performed by Apache protects against invalid requests being used to access content which would otherwise be inaccessible.
Since the SNI field is in the TLS client hello message send by the client before anything has been send by the server, it is possible to construct a lightweight frontend that knows nothing about HTTP and very little about TLS but still capable of dispatching TLS connections to different backends depending on the hostname.
Such a frontend would only need to know enough TLS to parse the client hello message and extract the hostname. Once it has that it can pass all the data unmodified to separate HTTPS backends. Only the backends need the server key needed to establish the TLS connection.
In this setup the frontend will never be able to know what hostname was send in the HTTP host header because it cannot decrypt the traffic. Thus it is impossible for such a frontend to compare the two hostnames.
This setup does allow multiple domains to be hosted behind a single IP address, even if the HTTPS servers themselves know nothing about SNI. However if the HTTPS servers know nothing about SNI, it is possible for a client to send a corrupt request in which frontend and backend see two different hostnames for the same HTTPS request.
It is possible to configure the frontend and backend such that a certain vhost is only reachable by telling frontend and backend different hostnames.
If a vhost is unreachable for every valid HTTPS request it can reasonably be considered a vulnerability if said vhost can be reached by sending an invalid HTTPS requests. If the backend is an Apache version with SNI support the check you ask about will protect against the vulnerability.