Yes, it's hardware registers. Could be a better idea to generate that from some more compact format, though.
The problem is the language and toolchain for OS device drivers cannot consume the manifests RTL designers use to enumerate registers, and and RTL designers rarely share the manifests and toolchains they use to generate source files for the OS developers. Instead, it is common to generate and share sources for the entire MMIO space of every supported chip revision.
To eliminate the source bloat this produces, OS driver developers would need to work with RTL design teams to release IP sanitized register manifests and tooling that can generate saner outputs for their own consumption. This is fairly specialized work and there is not a strong business incentive for most large firms to support it.
Removing unreferenced definitions from open source patches would also underscore the fact that driver code is already largely inaccessible to contributors that don’t have access to hardware specifications. The few that persist without it probably appreciate that the full listings are still published somewhere.
These headers are likely generated from their internal RTL, and somewhat part of the documentation to allow other OSS users to understand the interface. Even if most aren't used by most client drivers, and "just" some internal detail of their firmware/GPU command processing, or even optional and completely unused in current drivers, they may be useful to the community if the host can see and modify them.
Sure, you could argue that should be "split out" from the headers and documented separately, but at this point I'm generally happy for the hardware companies to give the community as much as possible and let them decide what's relevant.