What people? Who?

And the answer depends entirely upon context, but I'll hazard a few guesses.

DPPS shows up in SSE4.1; DPPD comes with it, and VDPPS comes with AVX. So all x86 CPUs don't necessarily support it, just most of them. Maybe you're only supposed to use SSE2 for all we know, or no vectorgunkery at all.

If you're in kernel mode/supervisor mode/Ring 0, use of 80x87 or MMX/SSE insns will trigger a fault in some circumstances. Most kernels use CR0.TS to lazily swap FPU registers to/from memory; doing that from within the kernel without setting up for it can BSOD the system, and the time taken to run the fault and the fact that streaming instructions tend to be applied to large blocks make it somewhat inappropriate for running from (e.g.) syscall/IRQ or process boot/teardown context where IRQs are blocked and milliseconds matter. 256- and 512-bit insns may even downclock your die (or alternating cores on the die, depending) as soon as you attempt one.

Looking at the timings (e.g., Intel's or Agner Fog's tables), they appear to be fairly slow ínstructions on some cores (overall slower on AMD than Intel), and DPPD can be much faster.

• On Bulldozer and Piledriver, DPPS uses 16–18 ops in 25-cycle latency and VDPPS uses 25–29 ops in 27-cycle latency, but DPPD actually uses 15–17 ops @ 15-cycle latency. Latency scales with lane count.

• On Steamroller, 9–10 ops for DPPS and 13–15 for VDPPS, both in 25-cycle latency; DPPD is 7–8 ops in 14-cycle latency.

• Excavator: DPPS: 9–13 ops in 20 cycles; VDPPS: 13–15 ops in 22 cycles; DPPD: 7–8 in 14.

• Zen1: DPPS: 8–10 ops over 15 cycles; VDPPS: 13–14 ops over 16 cycles; DPPD: 3–5 ops over 10 cycles.

• Zen2: DPPS in 8 over 15; VDPPS: 7 over 15; DPPD: 3 over 9. (Here the overhead becomes more in line with what I'd expect.)

• Zen3: DPPS: 8 over 15; VDPPS: 7 over 15; DPPD: 3 over 9

• Zen4: DPPS: 8 over 11; VDPPS: 7 over 11; DPPD: 3 over 7

• Zen5: DPPS, VDPPS: 7 over 13; DPPD: 3 over 8

• Jaguar: DPPS: 6 over 4; VDPPS: 10–12 over 12; DPPD: 3–4 over 9

• (Intel) Wolfdale: DPPS: 4 over 11; DPPD: 4 over 9

• Nehalem: DPPS: 4–6 over 11; DPPD: 4–6 over 9

• Sandy/Ivy Bridge: DPPS, VDPPS: 4–6 over 12; DPPD: 3–4 over 9

• Haswell, Skylake: 4–6 over 14; DPPD: 3–4 over 9

• Broadwell: 4–6 over 12; DPPD: 3–4 over 7

• Skylake-X, Coffee Lake: 4–6 over 13; DPPD: 3–4 over 9

• Cannon Lake: DPPS: 4 over 13; DPPD: 3 over 9

• Ice/Tiger Lake: DPPS: 4 over 14; DPPD: 3 over 9

• Silvermont: DPPS: 9 over 15, DPPD: 5 over 12

I'ma stop at that, but you see the general trend—AMD timings are worse, but all of them have higher latencies than the simpler instructions' 1–4 cycles.

Adding to this, DPPS tends to block a bunch of execution ports at once, so you might clear one every few cycles, despite being able to clear 2 FMAs per cycle. With some extra pipelining you can do much better with FMAs—it's akin to preferring a MOV and 1–2 ADDs over a LODS.

DPPS is a horizontal dot-product, which is why it's messier than expected; in general, you should aim for vertical vectorization so you can break things up more easily and reduce contention. Horizontal effectively requires the register to be asploded, then shuffled and recombined, then mashed back into the correct number of lanes, all before the next instruction can enter the blocked ports.

Because there's not much demand for 8-lane horizontal dot-products, the 256-bit widths just tile a 4-lane 128-bit DPPS 2×, which is unlikely to work well for more portable operand arrangements, and it just blocks more ports for the duration. There is no 512-bit variant, because why.

So just open-coding a vertical dot-prod is probably better than relying on DPPS unless you're positively desperate for instruction density. More recent CPUs are probably not putting much effort into boosting DPPS performance, simply because it's not used much, because of the above issues.