One of the two parts of verifying a TLS server certificate is what I described as 'making sure that this valid certificate is actually for the server you're talking to'. This is done by verifying that the hostname you're connecting to appears in the TLS certificate's Common Name or Subject Alternative Names fields (CN and SAN respective), which is how TLS certificates specify what hosts they're for. I have come to feel that there are two reasons for doing this verification, and doing it by insisting that the hostname you're connecting to is in the certificate.

The first reason is to verify that you are connecting to the real server for hostname X, instead of a server that an attacker or a third party (such as a captive portal on a public network) has interposed in the way. This is the obvious reason, the one everyone thinks of (me included until very recently), and it is where most of the threats to TLS connections are; you don't want people gaining access to cookies or credentials or whatever by faking out a HTTP web server, a TLS protected IMAP or POP server, or whatever.

The second and more subtle reason is to insure that whatever you're connecting to is actually intended to handle traffic for the particular hostname you're connecting to. If you are talking to the real host but to something that's not intended to handle such traffic, sending traffic to it anyway is potentially dangerous. Perhaps you're going to be sending live traffic to a debugging server that's configured with copious logging that is going to wind up writing live credentials to log files. That's bad. Perhaps it's a HTTPS web server that is going to see what it thinks is a non-official name for itself and will serve you a permanent redirect to its official hostname, which your web browser will cache for a long time; that's at least inconvenient, and bad for non-technical users.

There are many possible things that can go wrong if you're not actually talking to a service that is supposed to handle hostname X, even if hostname X is really handled by the server. Requiring that the hostname be in the TLS server certificate doesn't completely guarantee that the service properly handles that hostname, but it's at least a reasonableness check; if the hostname is not in the TLS server certificate, something is certainly wrong and the safe thing is to not continue.

By extension, this means that programs probably shouldn't continue if the hostname isn't in the TLS certificate even if they're absolutely sure (for some good reason) that they're talking to the right server.