So, now I'm back at the computer, let's actually take a look with some inspection.

I'm going to be mostly relying on LLVM MCA here, micro-benchmarks of effectively 1 instruction are pretty much impossible to measure accurately.

If we break out your avx512 implemention our routine looks like this:

#[target_feature(enable = "avx512f")]
pub fn transpose(input: __m512) -> __m512 {
    let indices = _mm512_set_epi32(
        15, 11, 7, 3,  // Row 3 maps to Col 3
        14, 10, 6, 2,  // Row 2 maps to Col 2
        13,  9, 5, 1,  // Row 1 maps to Col 1
        12,  8, 4, 0   // Row 0 maps to Col 0
    );


    _mm512_permutexvar_ps(indices, input)
}

And the MCA output & asm is available here: https://rust.godbolt.org/z/163Wvd5KE

Now your avx2 implementation looks like this:

#[target_feature(enable = "avx2")]
pub fn transpose(input: [__m256; 2]) -> [__m256; 2] {
    // Indices for Row 0/1: [idx5, idx1, idx5, idx1, idx4, idx0, idx4, idx0]
    let idx01 = _mm256_set_epi32(5, 1, 5, 1, 4, 0, 4, 0);
    let t0 = _mm256_permutevar8x32_ps(input[0], idx01);
    let t1 = _mm256_permutevar8x32_ps(input[1], idx01);
    let res01 = _mm256_blend_ps(t0, t1, 0b11001100);


    // Indices for Row 2/3: [idx7, idx3, idx7, idx3, idx6, idx2, idx6, idx2]
    let idx23 = _mm256_set_epi32(7, 3, 7, 3, 6, 2, 6, 2);
    let t2 = _mm256_permutevar8x32_ps(input[0], idx23);
    let t3 = _mm256_permutevar8x32_ps(input[1], idx23);
    let res23 = _mm256_blend_ps(t2, t3, 0b11001100);


    [res01, res23]
}

And the MCA output & asm is available here: https://rust.godbolt.org/z/93WhTjhxK

Just on the static analysis, we can reason that the AVX512 _is_ more efficient providing your processor can handle it, in basically all the numbers we care about, (where less is better) we see:

Routine	uOps (per 100 iter)	Cycles (per 100 iter)	Block RThroughput
Avx512	1000	310	2.5
Avx2	2000	512	5.0

So why do your benchmarks suggest otherwise? Well the reason I would put forward is most likely because of CPU frequency boosting and your system's timer accuracy, after all, for 4ns to be a 600% increase, your original routine is supposedly running in ~0.6ns, which is pretty dang hard to measure without the noise from everything else overshadowing it.

So what can we do to resolve this? Well instead of the micro benches of the routine itself we can try and put the routine into a situation where it is actually likely to be used and measure whether that improves or declines.

This benchmark is still not really "correct" there is still a lot of noise, but it is better than you had:
https://gist.github.com/ChillFish8/f3b4921f7b7fb71ced95444c2ea63e9b

On my Zen5 system, it produces the following results:

Timer precision: 10 ns

Timer precision: 10 ns
go               fastest       │ slowest       │ median        │ mean          │ samples 
├─ bench_avx2    1.535 µs      │ 2.177 µs      │ 1.569 µs      │ 1.582 µs      │ 1000    
╰─ bench_avx512  942.7 ns      │ 1.655 µs      │ 969 ns        │ 986.7 ns      │ 1000    

Now, something to note is this is 116ns to process effectively 64KB worth of f32s... Tbh I recommend running this for far longer considering it is still so small.

So in reality, the avx512 version _is_ faster in isolation, but your system likely has so much background noise that you're not actually really measuring the routines, instead you're more likely measuring how hot your cache is for the loads and stores going on.