This post cites sources that actively contradict the points it attempts to make. It provides a wealth of useful aggregation of information against the points it makes.

Let's us begin

    However, there are also deterministic frequency 
    reductions based specifically on which instructions you
    use and on how many cores are active (downclocking).

As you are likely using AVX-512 in a cloud deployment you don't have access to any of the information, and are likely sharing that hardware who may not respect the same engineering rigor.

Also, nobody setting there CPU affinity to ensure the down-clocking stays on a single core. You have to pray the scheduler doesn't shuffle your workload around. This requires a lot of platform specific C and most people are writing Java/Go/Ruby/Python where doing bit twidling NUMA management is impossible, furthermore the information you have access to in a cloud environment (which is where you'll be using advanced AVX-512 unless you work for Amazon, Google, Intel, or Cloudflare) may just lie about core count, and NUMA architecture.

Also this is just false [1]. Running AVX-512 adjusts the BASE clock for the package. There are throttling attempts to ensure every other core on the package throttles back. This is a package wide effect, not a per-core effect.

    Light instructions include integer operations other than
    multiplication, logical operations, data shuffling
    (such as vpermw and vpermd) and so forth.

This is false according cloudflare [2] which you've linked. They test your "light" carry less adding, shifting, and xoring (these are the only operations in ChaCha20 [4]). It cost too much.

    We have chosen to only include two columns.

I'll include the whole thing [3]. Wow yeah the entire package's power curve is changing. The base clock, cores not effected, all their clocks are changing. Its almost like having 1 out of 24 cores still effects all 24 cores....

    For example, the openssl project used heavy AVX-512
    instructions to bring down the cost of a particular
    hashing algorithm (poly1305) from 0.51 cycles per byte
    (when using 256-bit AVX instructions) to 0.35 cycles
    per byte, a 30% gain on a per-cycle basis. They have
    since disabled this optimization.

The literal example to show AVX-512 is good at ends with statement that people using AVX-512 are now actively avoiding it.

This is less then content, do you have an agenda or are you just an idiot?

[1] https://en.wikichip.org/wiki/intel/xeon_silver/4116

[2] https://blog.cloudflare.com/on-the-dangers-of-intels-frequen...

[3] https://en.wikichip.org/wiki/intel/xeon_gold/5120

[4] https://en.wikipedia.org/wiki/Salsa20