Part of the problem is that handles on directories on which one can then use the the *at family of syscalls are not first-class citizens in many programming languages. Which in turn might be due to portability concerns with windows, e.g. Java's SecureDirectoryStream isn't available there[0].
Apparently windows does have an openat-like API[1], but it's low-level.
Programmers aren't using them because the language standard libraries point them in the wrong direction.
Weird that you need to dip down to an Nt* function to open a child given a parent handle. It's not like it's unheard of to be able to do that in the Windows API. The registry is also a hierarchical system and opening any key requires passing in a parent key handle (the root handles are predefined).
It's a quirk of history, imho. If Win32 had been written without concern for what came before, it probably would have more closely followed NT conventions.
But it wasn't. It followed on from Win16 and DOS so, to an extent, it emulated DOS-style path and file handling. After all, that's what developers and users were familiar with. The Windows registry did not have all this baggage so it followed the style of the NT kernel.
Though this doesn't explain why Win32 never added CreateFileRelativeToDirectoryHandleW
Programmers aren't using them because the language standard libraries point them in the wrong direction.
[0] https://github.com/google/guava/wiki/Release21#user-content-... [1] https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a...