You should not underestimate the role of active individual contributors.
It is true that plainly raising a voice through several layers of management is difficult, but if you take into account that contributor can influence the project, the impact made on a project level can be much more noticeable than simple "screams from beneath".
In one of my past projects, things went exactly this way. Top management decided to freeze it (and by the way they had pretty good reasons for that). But while they were messing and fussing arranging the cumbersome administrative turns to finalize the project, several programmers were just having fun fixing bugs accumulated in a large backlog.
I think it also didn't hurt that we had quite a talented tech lead who managed to regularly spread the information about our progress "up the ladder": this week: 10 bugs fixed (total amount of fixes 50), next week: 15 bugs fixed (total amount 65) - and so on and so on, week by week, month by month.
After amount of fixes went well over 100, upper management decided to just make a "last" update release, "just to please customers before saying them final good bye". Update release was met with a lot of enthusiasm from clients and management decided to postpone the freeze and try yet another update release... long story short, a year later nobody was even talking about freeze and project went fairly well for a several years after that.
As a closer example, the very podcast example you refer to shows that small misconceptions at top level are not necessarily critically damaging. Think about it, as long as the Workplace has an active community of regular contributors, sharing a set of successful, productive values and working together on keeping the site up to these values, could it really matter much if someone else, no matter how high up the ladder, has somewhat different opinion.
I'd venture a guess that as long as it doesn't translate into a serious concern, it remains just that - an opinion - maybe interesting, maybe worth discussing, but not worth making a big deal of it.
On a more general note, at one of the soft skills training I've been told that for hierarchical organization to work reliably in a software related industry, it would better be designed to support information transfer over at least one level of management, ie ensuring that manager routinely communicates directly to subordinates of their subordinates. This ensures that important knowledge doesn't get stuck at particular level of management.
They also explained that such hopping over the levels is assumed only for communication - that is, if you're the boss, you still don't tell a subordinate of your subordinate what to do. Instead, you just learn how to more effectively manage your "direct reports", who in turn pass that further down the ladder.
An interesting, although maybe a bit extreme example of this approach has been outlined in an interview of Eric Schmidt to Harvard Business Review about his venture as CEO at Novell:
...you can’t just look at an org chart to find your most important employees. The key people here are our most creative engineers - they’re the smart people, the ones who control our future - and they can be very well hidden in the organization. They’re not necessarily at the top of any hierarchy.
I used a kind of algorithm to locate these people. A few days after I started, I was on the company shuttle from San Jose to Provo, where our engineering staff is centered, and I was sitting knee-to-knee with two engineers embroiled in a fascinating, heated argument. They were obviously two extremely bright people. I asked them to give me the names of the smartest people they knew in the company. They gave me a list, and over the next week I set up half-hour meetings with all of those other smart people, and I asked each of them to give me the names of the ten smartest people they knew. Because the smart people in an organization tend to know one another, I eventually found out who they were—about 100 in all.
I met and talked with each of them. It helped that, as an engineer myself, I understood their intellectual and technological needs and what their concerns were. I listened intently while they told me about their experiences and their frustrations...