In my field (server programming) readability trumps them all.
Nested g() and h() can be much better if they are even just 1% easier to understand. No one cares about a few extra CPU cycles, because we don't write system or database code.
Good question, for me it was always the focus, e.g. systems programming is an infrastructure to build applications, in contrast to applications themselves. In server applications we really don't care if something takes 100 bytes of RAM when it could take 1 byte. RAM is cheap, engineers are expensive. So something like Rust doesn't make sense to use.
Maybe I'm using the terminology wrong, and it's actually Applications Programming, but it's easy to confuse with mobile/desktop applications, where RAM does matter. In servers we pay for RAM/CPUs ourselves.
I will admit it is probably just some internal biasing from some unknown origin, but I always tend to think of server programming as a part of systems programming. To your mind, what keeps it out of the systems programming umbrella? I am not super certain about how programmers in your area break up the constituent parts of a server’s code, so maybe I’m thinking more along the lines of the ‘framework’/libraries your code is executing within.
Is this more of a ‘server programming is not systems programming because we are just implementing the logic of what gets served’ vs. my assumption that server programming includes the how does the server connect to the world, cache things, handle resource allocation, and distribute/parallelize the computations required to serve data back to the user?