I think there's a strong argument to be made for Spectre being a programming mistake, with the programming in question being Intel and AMD's proprietary microcode formats. We'd consider a similar timing/information channel in C to be a programming mistake, so it's not clear why we should exclude one in a lower-level representation.
> with the programming in question being Intel and AMD's proprietary microcode formats
No, as far as I know, the design mistakes which lead to Spectre (and other similar vulnerabilities) are not on the microcode; these design mistakes are on an even lower level, in the hardware structures which execute both simple instructions (which are decoded directly, without going through the microcode engine) and microcode instructions. Most of what the microcode "fixes" for Spectre and similar do, is flipping a few "chicken bits" (to disable or bypass some of the hardware structures), and providing extra semantics to a few of the complex instructions (which go through the microcode engine) like LFENCE and VERW; these changes do not actually fix the problem (which is on physical hardware), but instead give software ways to workaround the issue.
You should argue instead that the programming in question is the VHDL or Verilog (or other proprietary language) which was used to generate the hardware.
And, in any case those are also not coding bugs either, but architectural design bugs. Any hypothetical smarter, more suspicious HDL would have been wholly unable to prevent them, because the hardware is working exactly as designed and specified. The designers actually knew all about the flaws, they just thought they didn't matter.
Spectre