The depth of knowledge required to work on something tends to scale with how much performance is needed, or how large the impact will be. I feel this should be obvious, but maybe the reason we're having to defend shallow technical knowledge here might be because we're getting pushed to understand things deeply regardless of the performance/impact of the actual jobs.
I also think it should be fairly obvious that some jobs can be accomplished by only having shallow or ad-hoc knowledge because they work on low performance/impact, but are still needed by someone, and thus require an employee.
What has not been obvious is why we can't differentiate roles that require deep vs. shallow knowledge officially, because there is still quite a lot of ambiguity in the actual work demands of "Software Engineer" (or "Software Developer") which makes this kind of defense in the OP necessary.
Most of the time you should be working on both, sometimes you do shallow work, sometimes you do deep work and you naturally build a deep understanding of the pieces of the stack you mostly work with.
I find it hard to believe anyone does serious development work without some deep understanding of a piece of what they work on, the folks I've met that did that didn't last multiple review cycles.
Some people think I'm effective at work because I have a deep understanding of the system my team owns. There are projects we take on and decisions we make that do depend on that understanding. However, what's far more important 80% of the time are the wide-ranging shallow understandings I have of other systems that we interact with (sometimes directly, sometimes highly indirectly). I can't imagine being able to be successful in my role without both, but I see folks overindexing on the former pretty frequently.