Are certificates without DNS fundamentally flawed?

However, in this scheme, couldn't an impostor just present the certificate after getting it from the real server?

An impostor cannot present, and take advantage of, the real server's certificate unless it also has the matching private key. This is true whether the SAN DNS entry or IP entry are used to identify the certificate being presented.

When the attacker sends the server's certificate, the client will encrypt a shared secret (used to generate the symmetric encryption key for the session) with the public key of that certificate. The attacker will then be unable to recover the secret since they don't have the certificate's private key, so they won't be able to complete the TLS handshake.

For inspiration, look at how SSH key exchange works:

The client maintains a table of "known servers" that matches an IP address to a hash. When connecting to a server, the client receives the server certificate (public key) and computes the hash of it, and looks up the server's IP address in the "known servers" table.

If the client has seen this server before, it can compare the computed hash of the certificate with the one it has recorded for the server. If they match, then everything is fine and the connection continues. Otherwise, the SSH program will throw up a big warning message and refuse to connect.

When the client connects to a server for the first time, the user is notified that we haven't seen this server before, and offers to add the server's certificate to it's known servers table. This step can be bypassed by manually entering the server's certificate details in the known servers table.