If the CN (or other parts of the certificate like SAN) is usable for authentication depends on how much you can trust the one who put the CN there to properly verify the value. For example with a self-signed certificates you cannot trust the CN at all since you cannot verify who created the certificate in the first place (anybody could) and thus cannot trust this one to properly validate the value in the CN.
With certificates issued for domains by a public CA it depends. If this is a cheap/free DV certificate the issuer if the certificate just checked that the owner of the certificate had at least for a short time partial control of the domain - either over the domains DNS, the domains web server or maybe the email (depending on the verification method). This could have been an attacker as recent events show again.
EV certificates on the other hand have more complex verification and thus are much harder to spoof.
Thus, if you can trust the one who puts the subject in the certificate to properly verify that the claimed owner is the actual owner and if you properly verify the certificate (issuer, expiration, revocation...) and if the sender of the certificate can prove ownership of the matching private key (done when used for authentication inside TLS) and if you can be sure that the private key is actually kept private by the owner (otherwise it is hopefully rejected) - then you can trust the value in the CN/SAN and use it for authentication.
And this is what is actually done in TLS: the server certificate is checked by the client to make sure that it talks to the right server (i.e. no man in the middle). Additionally a server might request a client certificate to authenticate the client. In protocols like SIP where each peer can be client and server it is not uncommon to have such mutual authentication (i.e. both server and client certificate) where the same certificate is used as server certificate when acting as server and as client certificate when acting as client.