I find the term "low-level" to be an ambigious one. In my experience it partitions into two forms that I call low-level, and low-high-level. Low-level is anything directly touching the hardware, such as device drivers, OS kernels, firmware, and microcode. Low-high-level is anything just a level about that, including the lower levels of graphics programming, compiler backends, linkers, systems libraries, software runtimes, network code, and so on. I think low-high-level is an appropriate characterization in e.g. computer graphics since even using say Vulkan, one programs against an abstract model of a GPU, instead of touching the GPU directly. My mental model of the lower levels of computer graphics in that sense is that the platform APIs are different compiler backends for implementing rendering models, and the domain ontology is buffers, shader binaries, and locking primitives, with the system being built on those two or three ideas.

In either case, in low-level code and low-high-level code, the number of ideas one deals with is many fewer than in the higher levels of the stack. At the end of the day, computers are really fancy calculators, and the ontology at that level of the stack only consists of a handful of things. A consequence of it is that one reuses the same handful of ideas in myriad different ways. It's part of what makes the lower levels of the stack both fun, and monotonous at the same time for me anyway.

I cannot say whether low-level software or low-high-level software is easier than higher level code. One deals with fewer ideas, but the picky details matter a lot more. Hence why e.g. systems languages generally do not have the abstraction power that higher level languages do, but they allow you to directly manipulate data. With the higher levels, there's an explosion of ideas (far more different problem domains and business domains to consider up there) but one gets to take advantage of good abstractions and good infrastructure to help. I do find that the difficult/time spent per LOC ratio is a lot higher with low-high-level code than high-level code, but low-high-level code is also a tiny fraction of the entire ecosystem. One side benefit of experience in the low-high-level region in particular is that I have yet to run into a software system where having a sense of how that stuff works wasn't hugely beneficial. Since there are relatively few ideas that turn up everywhere in computer software, grokking them has a massive power to weight ratio for working with the higher levels of the stack, especially when debugging and stuff. At least I have yet to find time spent down there to be time wasted.