As a system administrator, I work in many different environments
Many people work primarily or entirely in a single environment (for example, their work laptop). For many people, this makes it quite worthwhile to significantly customize that environment, carefully curating things like their editor, setting up an advanced shell configuration, and so on. I'm not one of those people. It's true that I have a very customized X desktop, but it's more that I work through that environment than that I work in it. My actual work takes place in a disparate set of environments on a disparate set of systems.
I do a fairly large amount of work (as much as I can reasonably manage) on either my own desktop or in my primary environment on our Ubuntu servers, where I have a NFS mounted home directory, X forwarding, and so on. In both of these environments I have a custom shell, Git aliases, a relatively evolved GNU Emacs configuration with multiple packages, LSP servers for various things I use, and so on. But my energy to keep several copies of this environment in sync has limits and so I don't go too deep into various other things I could customize.
(As a practical matter much of this environment is also relatively old, inherited from a past era when I dealt with many fewer systems, and I might not recreate it if I was starting from scratch today.)
However, I also do a lot of work in additional environments. This can be as myself on systems that don't NFS mount my normal home directory, as root on various different systems that have my regular environment, as root on systems that don't have my regular environment, and sometimes as other accounts on some of our systems. Often these environments are shared with my co-workers, who don't necessarily agree with my tastes. In all of these other environments I have limited ability to customize things and often limited energy to make and update extensive customizations.
This is a common pattern in system administration but not a universal one. In this day of fleets of cattle that are run by orchestration systems, a system administrator may spend much of their time in their own desktop environment, editing code and orchestration configurations locally and then pushing them out; ssh'ing in to some random remote server to do something on it would be an anti-pattern that's used as rarely as possible. But this isn't my pattern of system administration, and instead I follow the much older one of working on all sorts of accounts on all sorts of systems.
All of this creates biases in what I'm interested in learning and customizing today. I need to maintain at least a basic ability to function effectively in a random login on a random, mostly or entirely un-customized Ubuntu server. And because I regularly work in those environments, there's a higher payoff for learning things that apply across all of my environments than things that only apply in my primary high-touch ones, unless it's an activity that I'm only likely to do in the high-touch ones (such as doing significant amounts of programming).