Why can't a hacker just obtain a new SSL certificate for your website?

Being able to MitM a certificate authority is perhaps not as trivial as you imagine. You don't know what machine they're using to evaluate ownership, and hopefully they aren't doing this over Starbucks wifi.

Certificates apply to domain names, not machines or IP addresses, and thus ownership is generally not verified by testing responses given by a certain HTTP server. For instance, taking a look at Mozilla's requirements for CAs,

We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:

• all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate;
• for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;
• for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant’s behalf;
• for certificates to be used for and marked as Extended Validation, the CA complies with Guidelines for the Issuance and Management of Extended Validation Certificates version 1.4 or later.

So you would need to either MitM the connection between the CA and a DNS server, or compromise the site's DNS (the more likely one).

The certificate issuer promises to only issue a certificate for your domain name to people who can prove they have control of that domain

I guess a man in the middle attack against both HTTP and SMTP could be used to deceive the issuer and thus get a "domain-control validated" certificate to which the attacker is not entitled, this fraudulent certificate could then be used to impersonate your site in a man-in-the middle attack against HTTPS traffic. if the HTTP ans SMTP servers are different then two MITM attacks will be needed.

The extended validation certificates (like used by banks) that display a long green message in the address bar require more steps than just proving control of the domain name, and could probably not be fraudulently acquired as easily.

HPKP (HTTP Public Key Pinning) is a security policy delivered via an HTTP response header that:

• allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future
• protects a host website from a security compromise at a Certificate Authority where rogue certificates may be issued
• allows a host to deliver a set of fingerprints to cryptographic identities that the User Agent (UA) should accept for the site going forwards
• is a Trust On First Use (TOFU) mechanism and the UA must establish at least one secure session with the host to receive the header intact. Once the header has been received, the UA will cache and apply the policy as per the directives included in the header

Answering your question: a host that implements HPKP prevents hackers of using new/rogue SSL certificates.

HPKP may be easy to setup, but it should be carefully done and it is "essential" to have backups:

• the most ideal solution is to include the fingerprint of the current TLS certificate and at least one backup
• the backup can be the fingerprint of a Certificate Signing Request (CSR), thus avoiding the need to purchase a backup certificate
• if the private key of the certificate were ever compromised, a CSR could be used in order to request the signing of a new public key (for this to work, the CSR has to be created with a brand new RSA key pair and stored securely offline)
• as the fingerprint of the CSR was already in the HPKP header, switching out to the new certificate can be accomplished without a problem
• using this method, if any CA was ever compromised, even your own CA, any rogue certificates that were issued for your domain would not be accepted by a browser that had received the HPKP header
• because the fingerprint of the rogue certificate has not been received and cached by the browser, it will be rejected and a connection to the site won't be allowed

This means that if all your backups are lost then:

you only have until your current certificate expires to get a new policy out to all of your visitors!

Perhaps this is why not many websites currently implement HPKP (scan for a few examples in securityheaders.io and you may find that most online banks do not, e.g. JP Morgan), but it does specifically address/solve the problem raised by your question.