The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for direct TLS.
Server operators should not expect multiplexing (via ALPN) to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated direct XMPP-over-TLS). This is a result of relying on ALPN for multiplexing, where ALPN might not be supported by all devices or may be disabled by a user due to privacy reasons.
-If the _xmpps-client (or _xmpps-server) target is set to . (dot), this indicates as per &rfc2782; that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up _xmpp-client (or _xmpp-server) records. The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).
+If the _xmpps-client (or _xmpps-server) target is set to . (dot), this indicates as per &rfc2782; that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up _xmpp-client (or _xmpp-server) records. If the initiating party cannot connect via either SRV record, it SHOULD perform A/AAAA fallback to port(s) of it's choice (perhaps 443, 5223, etc) because, in the absence of DNSSEC, SRV records cannot be trusted.
Direct TLS provides AT LEAST the same level of security as STARTTLS, and more privacy without ALPN as using STARTTLS leaks that the underlying protocol is XMPP, while any direct TLS stream should be indistinguishable from any other direct TLS stream. Direct TLS provides more security than STARTTLS if &rfc7590; is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the STARTTLS and direct TLS logic as well. All SRV-based connection methods are subject to DNS modification/stripping/spoofing of SRV records in the absence of DNSSEC.