Because with a DOS type system you broadly needed an IRQ for each event and so lots of IRQ levels to allow events to mask other events simply. With a real OS you pretty much just need a single event and let the kernel figure everything else out (actually it’s convenient to have a couple of levels for NMI and real-time).

So I’m guessing that with 64bit and knowing that you aren’t backward compatible supporting some DOS app on a 386 they took the opportunity to simplify.

I just want to add a couple more points about interrupts in a modern system. I will TRY to make the layout clearer.

The interrupt descriptor table (IDT) is the protected mode replacement for the interrupt vector table (IVT). The base address for the IDT is stored in a CPU register and it can be located almost anywhere in memory.

You can view the contents of the IDT if you have the kernel debugger by using the ! idt command. Apart from the expected 32 odd exception handlers and a few legacy devices you won’t find much in the modern IDT. I will try to explain why later.

Every interrupt causes the CPU to enter kernel mode so kernel mode code can deal with them.

Interrupt request level (IRQL) zero is not really a level as all interrupts are allowed. User mode code usually runs at IRQL zero.

The kernel and drivers use software interrupts for issueing deferred procedure calls (DPC’s), sheduleing threads and asynchronous procedure calls (APC’s). DPC/thread dispatch is done at IRQL two and APC’s at level one.

The kernel and drivers always try to keep the IRQL as low as possible. These days driver interrupt service routines often do little more than acknolage the interrupt before calling a DPC to carry out any data transfer. This way the IRQL can be dropped from device level as quickly as possible.

Sorry I said I would explain the lack of IDT entries but I have to go out. Message signalled interrupts, MSI-X and x2 local APIC are the cause. If anyone is interested please ask 😊

The answer is actually simple and the answers here fail to address it. Yes, the 8259 PIC had only 8 priority levels configurable in the OCWs. The default was fully nested priority where IRQ0 had the highest priority and IRQ7 had the lowest. 32 bit CPUs however did have APICs; for instance, the Pentium Pro (32 bit) had a LAPIC with 256 vectors. IRQLs for the 8259 PIC is based off of the IRQ because IRQs were mapped linearly to vectors, and it is based off the vector for the LAPIC. IRQLs are the priorities. The current IRQL of the logical core is the current priority mode of the logical core which gets written to the TPR of the LAPIC to mask interrupts less than the IRQL. The reason windows decreased the number of IRQLs is probably because the standard devices simply don’t need that many priority levels between them because it doesn’t change the behaviour of the meaningful software defined IRQLs above and below them. One device interrupting another is not so important as ensuring any device can interrupt APC/DISPATCH level and is masked at SYNCH level cores. Only device IRQLs were collapsed and a few other changes were made like power level and high level being made the same. But this is only because the prior system was more verbose and this change was able to be made to made. The APIC allows for 240 priority levels:

Each interrupt vector is an 8-bit value. The interrupt-priority class is the value of bits 7:4 of the interrupt vector. The lowest interrupt-priority class is 1 and the highest is 15; interrupts with vectors in the range 0–15 (with inter-
rupt-priority class 0) are illegal and are never delivered and only exceptions use them — Exceptions are received by the CPU regardless of either
TPR’s or IF flag’s state, so that the concept of IRQL does not apply to
them. Because vectors 16–31 are reserved for dedicated uses by the Intel 64 and IA-32 architectures, software should configure interrupt vectors to use interrupt-priority classes in the range 2–15. Each interrupt-priority class encompasses 16 vectors. The relative priority of interrupts within an interrupt-priority class is determined by the value of bits 3:0 of the vector number. The higher the value of those bits, the higher the priority within that interrupt-priority class.

The Windows PnP manager will make sure that the IRQ that gets assigned is the same as the requested priority level by the driver which will be put in the interrupt object as well. This allows for lazy IRQL.

See:
https://stackoverflow.com/a/54537563/7194773

Its a bit more complicated i’m afraid. Still haven’t got to the bottom of it but i’ll tell what I know.
Windows maintains a note of the IRQL its using for EACH logical CPU in what it calls a processor control block which is just a data structure not any sort of register. There is also an interrupt descripter table with 256 entries that point eventually to interrupt service routines. I say eventually because first we go through an interrupt object that keeps a note of the interrupts assigned IRQL and also the interrupt despatcher.
32bit X86 CPU’s did not have any notion of IRQL as such but the designers of Windows decided they would have 32 of them. The IRQL of a device was decided by taking its vector number and deviding it by 16. Remember the vector number is not the same as the IRQ pin number(any pin can have any vector between 32 and 255 because the first 32 vectors are reserved for exceptions). To make this work Windows has to program the PIC chip to mask out interrupt pins that are below the level that it has recorded for the CPU. This changed with X64 because the CPU was given a model specific register that actually set the CPU at an IRQL between 0 and 15. The designers of windows have made use of this to simplify things.