TLS client implementations will tend to try and do hostname verification by default for remote TLS endpoints (servers). The client connects to the server, and as part of the negotiation the certificate chain is checked (valid, signed by a trusted CA etc.) and the hostname is also verified (is the hostname that I'm connecting to listed in the server leaf cert SAN list).
As I understand it, the purpose of the hostname verification is to make sure that the certificate being presented by the server was issued for that specific server, so as to prevent a valid and trusted certificate issued for evil.site.com being used for connections to an endpoint reachable as, say, gmail.com. If an attacker controls where a target's packets go (including DNS), hostname verification is something that can prevent traffic being MITM.
However, in the case of a self-signed cert, the dynamic is slightly different. Mainly, the cert won't be trusted by the client by default - it is almost certainly not in the client's root CA list. As a result, a client wishing to make a valid TLS connection to an endpoint protected by a self-signed cert would need to explicitly configure themselves to add the cert into the CA list (or even configure it as the only CA for this connection). By doing this though, the client is effectively ultimately trusting this certificate. Any remote endpoint that presents the same certificate must surely also be trusted, no matter what name was used to access it.
If the server presents a leaf certificate that is the same as the one configured by the client to be a trusted CA for the connection, is there any value in doing hostname verification? If so, what threat is being defended against?