See: The Mythical Man-Month
I agree that making sure that your work is observable is important, and usually Management's attention needs to be called to where the observed changes are being made. This is not the same as holding you hostage in a meeting culture where you need to sit through everyone else's reports on their progress. Instead of people taking five minutes to write out their progress report to their manager, who can then skim the progress reports and the work for a full team in fifteen to twenty minutes, instead we hold everybody hostage for thirty to sixty minutes. Typically this is a syndrome of a culture where labor is not expected to document their work, and nothing will scale without pulling senior engineers off their IC work to synchronously bring people up to speed. This necessarily reduces engineering velocity to a crawl.
Nobody can speak as fast as a progress report can be read. Verbal meetings cannot be indexed or searched. All meetings should have a product - a decision, language that is agreed upon, written out, saved to a knowledge base. If you call too many meetings, it's a sign that you're not delegating authority enough.
The Mythical Man Month was also not saying adding manpower to a project makes it slower, simply that it potentially could and there's limits to parallelism.
Everything else mentioned rings true though.
Thus, some work may be immediately taken off your plate, without you having to dedicate your own time to training, etc.
Meetings suck. However they absolutely have a purpose, and really, sadly, you are never "held hostage" in a paid-for scenario.
Not everybody's time is worth the same, and it's a classic organizational fallacy to treat your employees' time as having equal worth. Simply put, five minutes of a senior engineer's time is worth more than five minutes of a junior engineer's time. This is clearly obvious even if you only compare their salaries (and not the value that each worker brings to the company). If their time was worth the same amount, we wouldn't hire juniors in the first place.
Thus, it's inherently unreasonable to use five minutes of a senior engineer's time to save five minutes of a junior's time. I expect juniors to struggle with something for at least a few hours before asking a senior for help.
This is besides the point that, if employees are documenting their work properly, there is less need to synchronously synchronize. "I don't remember, read the documentation, that's why I wrote it."
And let's not forget obviating the need for status reports entirely. I've been part of teams that got solid work done without ever having to give status reports to anybody. We'd ship early and often; our "report" was frequent results.
Use that time to read or browse HN or something.
Lets say one hour meetings per day. This means 8-1 = 7 hours of real work. If you work the 8 hours + the meeting, if you ever have to go back to the office, either you will have to work 9 hours to produce the same as WFH (since now you have to sit on the meeting), or drop in productivity and get scolded by a manager (you are producing 12.5% less)
The management situation you posted is also a bad management decision: https://blog.devgenius.io/why-adding-more-people-to-a-projec...
But i digress, fractally, outwards, not really caring..
I have never seen this happen in my entire life, nor would it be useful
Reporting does have value but has become way overdone.