It's likely that using OpenSSL bindings instead of go's implementation of various cryptographic features would provide a significant performance improvement for various tasks, especially on weaker hardware and devices with integrated cryptographic circuits. That's exactly what Golang-FIPS/OpenSSL does!
The one major caveat I could think of is that it's less portable than simply using Go, but I don't see why this should prevent the implementation of such a feature. A build constraint could serve to limit this feature to only hardware that would benefit from it.
The biggest problem would be that this would require mandating the use of CGo and also convert rclone from a static binary to a dynamic one with all its inherent issues of linking with the correct version etc.
That seems to be a pretty large caveat for what may be minor improvements overall because from what I have seen, the SSL handshake has never been a bottleneck for any remote transfers.
Go has nice assembly coded routines for the most common crypto routines and processors and these are very fast and take advantage of special instructions in the CPU. However it doesn't support everything and especially on older hardware which needs crypto accelerator support, go falls behind openssl.
That said Go keeps improving here. There have been various issues about this in the past #1061 and #1013 - those were both resolved by improvements in the Go SSL library.
TLDR - CGO is a massive pain and we want to avoid it! If there was a very compelling reason then we would consider it, but I think the Go stdlib has the most common ciphers and platforms covered which probably account for 99.9% of rclone's usage.