Wall of text incoming; I was trying to explore why I agreed with you and the parent post wholeheartedly while still finding some value in the "shield from the bullshit" concept, if perhaps not how it's commonly applied.
So I'm in an interesting position to comment on this, as a dev trying to transition into management. I've ALWAYS been on the full-transparency side as a dev, but have often had to defend that position to other managers and bosses, with the justification that I might scare the devs or distract them or have them focusing on things that aren't their core goal.
There's definitely a kernel of truth in that, but I've found most of the "grey area" is less ambiguous in practice; (e.g. don't be a rumor mill, don't get people worked up, realize there may be a proper time and place) and more importantly, _devs usually know most of what I would tell them._ They're not idiots. They have people they talk to, and they overhear things, they usually know how the games are played at some level and have some intuition that "something is happening." And by trying to hide this, and not being a partner and helper in wading through it/building confidence, you erode trust. So in terms of the "what's going on in the team" bullshit I'm pretty open, even if it's a bunch of political infighting and misaligned incentives, at least so the dev can understand the landscape and make sense of it.
The bullshit that I DO however think you can shield a dev from is the "Symptoms" of the above. Help balance out individuals playing favorites, individuals being biased against a certain dev, help a dev see if turmoil is coming and how they might navigate it, help a dev understand where motivations are pointed so they can avoid socio-political pitfalls, or optimize the decisions they make to drive their career to be responsive to the ecosystem they're in.
I believe one can be transparent enough to let a dev know WHAT is going on, but still provide them an ally and shield against potential negative impacts of it.