It's a long-running process that's waking up constantly for IPC+compositing duties alone.
If you're still on X I'd expect more of the compositing cost reflected in the Xorg process than gnome-shell.
But on a "modern" Wayland-based gnome session, the gnome-shell process encompasses what used to occur in Xorg. So all that time is now attributed to gnome-shell.
It's not like you just arrange the GPU with some buffers and never wake up to send it commands on what to draw when. The compositor is a rather busy process, esp. if you have many clients/windows active.
This stuff was easier to reason about in the Xorg days with WM "policy" running in a clearly separate process from the X "mechanism" side. Wayland tends to conflate everything, unless the compositor developers choose to use separate well-labeled threads for things like input/compositing/policy...
I don't personally use gnome so it's inconvenient for me to check despite mild curiosity. It may be interesting to look at a threaded view of `top` if you're on Wayland, and see if gnome-shell has clearly separated threads.
Interestingly, modern Xorg uses separate threads now, from this machine:
So gdrv0 alone has consumed 36.5 hours during my ~1.5 day uptime.
If this were a Wayland situation, that time would be reflected in my compositor process instead.
~83 hours for the main Xorg thread, which I presume is largely IPC but X also does heaps of crap from its huge protocol on-CPU so I think it's best to just ignore that.