Your question doesn't seem to be the reason for Subject Name, which is to identify the subject, but rather whether it works.
Gutmann writes colorfully and at some length on things that actually don't matter most of the time, although when they do it's very useful to know about them. Yes, the full X.500 naming scheme specified to be used in X.509 certificates in general is a monster. (Committee designs are traditionally depicted as camels, although in this case octopus seems appropriate.)
However, SSL/TLS certificates and particularly web server certificates -- which is the only kind most people encounter and the only specific case in your question -- avoid the issue by really using only the CommonName attribute in Subject(name) to contain a 'fully-qualified' domain (DNS) name aka FQDN, or possibly (but rarely) an IP address; or nowadays usually the SubjectAlternativeName extension to contain FQDN(s) and possibly IP address(es). Although in actual operation (especially at its current worldwide scale) DNS isn't perfect either, most people can understand it easily enough, and certainly the domainname in an
https:// URL is easy enough to see.
A legitimate CA should issue a certificate for a given domainname only to the 'owner' of that domain, although exactly what counts as ownership varies a little. You can visit each CA site and look at their application/validation rules and processes, or see CA/Browser Forum under Baseline Requirements which sets the (minimum) standards for CAs to be included in the truststores of most browsers and OSes (at least on consumer devices), and thus the ones most users end up trusting.
Thus, if the CAs do their job and attacker M can't either trick or force a trusted CA into wrongly issuing him a cert for domain D -- which has happened in a small number of cases, but not so many as to be a big problem -- M can't impersonate the website of domain D. Even though he gives you fake DNS (or IP routing, another possibility) he can't present and prove possession of the key for a valid cert for D and the SSL/TLS handshake fails.
Unless of course you, or the supplier of your browser or OS or device on your behalf, trusts a CA that issues bogus certs, for any of a range of reasons. For example, you can find probably a dozen Q&A here and other stack sites about last year's Lenovo Superfish fiasco: they added software to a large number of Windows PCs that used their own CA to MitM your HTTPS connections for the claimed purpose of providing more relevant advertising -- but they exposed the (fixed) CA privatekey and then anybody else could MitM you. They had to publish tools to remove the offending software and CA cert, and to catch any that slipped through the browser and OS makers also blacklisted their cert.