Not really, provided some data is already known, which is the case in TLS has well (either you know the public key of the server, or you trust a set of CAs)
"Secure communication in a single round-trip" implies securely transmitting to a specific audience without any correspondence beforehand and securely receiving information from them afterwards - which seems impossible - probably because it is.
If you relax the constraints to allow for shared state beforehand (which could only arise from prior communication-trips of some sort), you're just at RSA: cool to be sure, but coming up on 50 years old at this point.
As you say, if you want to have 0-RTT data, you must have some prior information about the server. This information can come in two main forms.
1. Have the client know the server's public key in advance. You can then do a RSA or ephemeral-static key exchange, as in gQUIC, OPTLS, or TLS Fasttrack.
2. Have the client and the server do an initial handshake and then reuse the symmetric key for future connections, as in TLS 1.3 and IETF QUIC (which uses TLS 1.3).
The public key version has a number of superficially compelling properties, in particular that you can publish the server's data somewhere like DNS ("0-RTT Priming") and thus have 0-RTT with the first connection. By contrast with the symmetric version you have to have a connection first. The public key mode also will work in this setting. However, making this work in practice has a number of challenges around authentication, anti-replay, anti-amplification, etc. Initially TLS 1.3 had both of these modes but we ultimately removed the public-key based one in favor of a symmetric-key based mode.
I’m not sure what’s the relation with RSA but you’re right that it’s simple. And that’s what noise has been doing for years. There isn’t much else to look at here, unless you specifically need tls you should be using noise
TLS 1.3 and QUIC both support 0-RTT modes as well (as noted in the original paper). Note that anything that runs over TCP of course first has to absorb the TCP round-trip (modulo TFO) whatever crypto it uses. That's why QUIC uses UDP, and the motivation for the use of UDP in TurboTLS.
