I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2].
Your right that implementing a secure RSA protocol by one's self is difficult. That's the idea of things like Noise, to make messing up your own protocol implementation harder (albeit not impossible). The other option is building on something like libsodium that has a good, well-documented API and is hard(er) to screw up.
TLS certainly works for a lot of things, it just doesn't work for everything. For that reason, something that bakes it in probably won't replace TCP.
[0]: https://blog.cryptographyengineering.com/should-you-use-srp/
My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch of code on top of Sodium to avoid passwords like '4K2m_chmJ$gD' which they feel wouldn't be suitable because it has the letter 'm' more than once...)
And you're right, that's pretty dopey with the password manager. I understand the point of password security measures, but just do something like pam cracklib. There's no such thing as an idiot-proof library. Honestly, that looks like the developer was being kind of lazy, using a constant size for things like max password length.
My only point here is that there are libraries that are well-tested, secure, and at least as idiot-proof as openssl. The increased ability to do the protocol wrong with something like libsodium is balanced by the increased ability to do the crypto wrong with something like openssl.
TLS-SRP bolts over the traditional TLS key exchange mechanism, which made sense, but in TLS 1.3 that entire mechanism is gone, keys are either pre-shared or they're always agreed in the first protocol burst using an (elliptic curve) Diffie Hellman method. So by the time you'd have a natural opportunity to do SRP the protocol has already agreed keys anyway.
I don't see how certificates are relevant at all? You clearly don't want a certificate if you intend a PAKE to provide mutual assurance of identity.
I think Colin grossly overestimates the chances of some bozo getting an RSA (of all things) transport protocol to work securely. My guess is that most attempts will end without it working at all (frustrating but safe) but a potentially very scary number would work in the sense that they seem to function as intended while not delivering the expected security through a combination of ignorance and inadequate testing. I particularly don't buy that a bozo who actually does get all that right can't instead write code against OpenSSL without ripping a hole in the universe. I don't like OpenSSL, but even I can see that it gets enough hard things right to be a useful contribution.