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.