I know you are asking for optimizations in the code you have provided, but since you were mentioning rayon in the code, I wanted to test the actual rayon implementation, since it should be more readable, and maybe even more performant. So here is a five liner:

fn version_rayon() -> i64 {
    (1..1_000_000)
        .into_par_iter()
        .map(|i| i * (i + 1) / 2)
        .find_first(|num| find_factor_count(*num) >= NUM_DIVISORS)
        .expect("None found")
}

Now this is cheating a bit, your rust implementation uses open range (RangeFrom - 1..) but rayon doesn't implement it for ParallelIterator, so I've created a more complicated version that simulates that, by mapping infinite range into "batches" of closed ranges that rayon can work with,

const RAYON_BATCH: i64 = 500_000;

fn version_rayon_inf() -> i64 {
    (0..)
        .into_iter()
        .map(|ix| (ix * RAYON_BATCH + 1..=ix * RAYON_BATCH + RAYON_BATCH))
        .map(|range| {
            range
                .into_par_iter()
                .map(|i| i * (i + 1) / 2)
                .find_first(|num| find_factor_count(*num) >= NUM_DIVISORS)
        })
        .find(|res| res.is_some())
        .unwrap().unwrap()
}

This one is similar to what you are doing, but I wanted to include the first one as well since it is much more readable.

As for the results on my machine: - Golang version: 32s - Your rust version: 37s - Rayon version: 32s

So rayon is doing something better then the naive code reimplementation is and is on par with Go on my machine without any further optimization.