In my personal experience, the best engineers I've encountered (and learned from) have understood every system, subsystem, and interaction, all the way down to the most fundamental foundational level. And this understanding allows them to make the best decisions (because they're equipped with the best information). This knowledge doesn't come by sitting down and studying how CPU architecture works when you're building a web application. But it does come from diving as deep as is required for any given task. So maybe if you're dealing with a web app performance bug and you have to crack open Chrome source code, trace it down to something that is compute-intensive, learn whatever C++ code is involved, understand how it utilizes the CPU, and learn about the specific architecture you're using that exhibits the problem, then you have ultimately obtained a significant depth and breadth of information, but at the end of it, you know and understand exactly why your web app performs the way it does, how to workaround it in your app, how to fix it in Chrome (or why you shouldn't), and how the CPU architecture affects the Chrome source code. Now you can apply Chrome, CPU architecture, and C++ to anything that is built upon any one of them (independently or otherwise). That's not to say you know everything about each of them, but you've learned things that will help you in the future in some cases.

The most important skill here is being able to diagnose a problem and fearlessly, relentlessly employ the engineering discipline of solving whatever problem/task is at hand, and not because of observed symptoms ("hey, I turned that knob and everything was OK! I don't know why, but I can close this JIRA ticket and move on with my life. I'm a 10X engineer!") but because you understand precisely what's happening. I made the mistake of the first decade of my software engineering career learning from trial/error and observations, and while those skills are useful in some cases, the best engineers are extremely disciplined about understanding the full depth of a problem before writing a line of code.

In a nutshell, I guess what I'm advocating for is do not blindly study man pages. The reason is because without a practical application for the knowledge, it seeps out of your brain and you forget it quickly. The exception (case in point, GP's example) is when what you're studying does have a practical application or is relevant to what you spend your time doing. This has always been my problem with academic curricula (sure, some people can learn well this way, and there's definitely a minimum foundation necessary that must simply be committed to memory). Even in basic subjects like maths -- the work is rote, and we maybe get a passing grade, but often without the understanding (or the depth of understanding) that is really the most important aspect of learning the subject matter.