Most "full featured" OSes do not use HALs - they are most commonly found in embedded development where you have to wrap a platform that otherwise has no mechanisms to inform the OS what is where.

Which is also related to how original NT used them. ARC (and its PC BIOS-based emulator, NTLDR) provided early boot ability, HAL provided "driver" to access platform, and the NTOSKRNL itself didn't have to worry so long as it was running on same base ISA and had all the necessary drivers loaded.

So for example on x86, there were HAL.DLLs for PC BIOS, "standard" PC BIOS multiprocessor, ACPI (uniprocessor and multiprocessor variants), Sequent, SGI Visual Workstation, etc.

To add to your point, Microsoft had originally envisioned that vendors would write their own HAL.DLL’s to make Windows compatible with their hardware, but it turned out nobody really had the expertise needed to do that, and Windows started to depend more and more on implementation details of the most common one, and at this point the idea is dead. Hardware vendors target one single windows HAL for x86_64, and porting windows to another platform requires rewriting/rebuilding all sorts of stuff, not just the HAL. It was a cool idea at the time that didn’t really pan out.

There was a certain level of custom HALs being written, but those depended heavily on the "shared development" model that Microsoft did with vendors, and a lot of hardware was shipping bog-standard PCs anyway.

The rare custom HALs were mainly for things like x86 NUMA systems, or from ports to alternate architectures.