I'm confused as to why you think you can replace all the things in TLS that provide security with some sort of magical SecureConn function. TLS is the secure connection, so much so that your code example is exactly what happens in Golang when you use the TLS library. net.TLS provides a Dial() and a net.Conn implementation.
Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.
Go write up the code to connect two parties. Just A and B. A knows about B and wants to connect to B specifically, B will talk to anyone, but wants to know exactly who. It's far more than just Serve and Dial, and often you have to involve a 3rd party, or know a lot of details about self-signed certificates and the particulars of authenticating them.
If it was just Serve and Dial with the guarantees I mentioned, we would be in agreement that it was easy and a suitable default.
> "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined."
I thought I was fairly clear in saying: less complicated == better. That is the way in which it is better, that I am now defining explicitly for you. If that's controversial then that probably explains most your disagreement. The complexity has to be so low relative to other solutions that it is more likely to be used than not.
I agree that simpler is better than more complex, but you're not saying what is wrong with the current approach. I gather you're upset about certificates (who isn't annoyed with X509?), but ultimately all you're saying is "I wish Serve and Dial were more secure, but without using the mechanism that specifically exists to make them secure." This is just one big No True Scotsman.
Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.