When you're in the meeting, everyone politely explains to you what they're doing and they say "yes" to your ideas, so you feel like you're making progress.
But when they actually need to do focused work, which you don't want to know the details of because it's too hard, they do far better outside of an oxygen-deprived, loud office that they need to commute to.
I definitely don't need to be onsite everyday to keep up-to-date with a manager. One call a week is already a luxury, some interactions via chat (where I can report some progress and stuff).
Mostly it's managers who want to see their team everyday and talk to them, I guess because it makes them feel like they are managing?
I switched from a technical position to a manager one one year ago. My team is remote mostly, myself included in different countries/continents. I do travel to the office to meet colleagues going to the office and having face-to-face time with some.
I don't need to see my team everyday but I do need to have a vision of what they are doing and busy with because we are working on a lot of different projects, pursuing sales opportunities and trying to balance the work based on skills/time available/opportunities to learn or emergencies. So I tend to do 1 team meeting weekly and weeklies with most of the time on the side at least, track project on slack/jira/crm and try to have a board view of my team while being read to deep-dive when needed.
Do I like being on site? Yes but mostly to talk with project manager and product owner, it is more easier to brainstorm/have meaningful discussions in a semi-informal setting of a coffee. For technical colleagues on my team, it is different depending on the tasks : creative/architecture/whatever or routine/operational.
Can't see my team on site everyday anyway but would prefer for some specific type of interaction.
Well that's just me trying to find my way in management so grain of salt and personal bias and imposter syndrome warning :)
The value in your comment is on bringing one aspect that makes the situation more "grey", but you lose it all by then depicting the situation as "managers are useless and devs don't need them", which is very black-and-white.
I'm not a manager and I'm not a dev (I work with data and often ended up coding my own system that sometimes ended up in production against my will), but I have observed a lot of devs who were saying "I'm doing fine on my own", and they were convinced it's the case, and ... they were not doing fine.
Some red flags are devs that complains that "the requirements are not clear" or "the company seems to not care about my effort". Sometimes it is true, but I've observed a lot of the time the same people also saying "just give me some requirements that I can follow step by step instead of explaining the bigger picture, I don't care of what this other team do, I'm busy" or "I redirect all the company-wide meeting invites directly to the bin folder" or "when I go into details of the code, the manager don't get it because it's too hard, but when the manager explains their needs and why it makes sense, I don't get it because I'm wayyyy too smart" or "when I go into details of the code, the manager don't get it because it's too hard, but when someone talks to me about something else than code, they have to learn to adapt to their audience and be happy that I pretend to listen to their boring work tasks".
They are truly thinking the problem is the others and incapable to even imagine their mentality is the problem.
The fact that the OP thinks you move the needle primarily by having great meetings together, and leaves out the engineering aspect completely makes it seem like he's the out of touch "ideas" manager, and for this archetype, the office is indeed a more comfortable environment - you can have coffee with everyone whenever you like.
This demonstrates that your logic "OP reaches this conclusion, so it's the proof that he does not understand the code, which is the problem" is wrong. If this logic was true, who do you explain that someone like me, who clearly understands the code (I've reviewed it, I've modified it, I've put stuffs in production integrating with their system, ...), agrees with some of OP's considerations?
When reading your comment, it is difficult to not be drawn to the idea that you are one of those persons I was mentioning, who are not understanding other employees needs and point-of-view and who interpret systematically any communication failing as "the other person's fault".
Meetings with such a person will cause the engineers to work around them instead of being lead by them. There's also no reason such meetings have to happen everyday at the office.
Most serious advancements are produced by single contributors tackling parts of the problem. Commitees are a place of power struggle, not technical progress.
I've been in meetings that were power struggle without any progress, I've also been in meetings that were really useful to solve the problem, way faster than the contributors shooting in the dark because they think they too smart to dialogue. The direction of the meeting depends way more of the mentality of the participants and on their skill to solve problems smartly than of the manager. If you go to the meeting with in mind the idea that the meeting is useless, obviously, you will stir it in the wrong direction (and apparently, you are prone to jump to the first cliché conclusion, I can imagine that you will interpret any contribution in the worst way possible). It does not mean that with participants with a better mentality, the meeting would not have been 10x faster than with single contributors tackling parts of the problem.
Don't get me wrong, shitty meetings happen. But if all the meeting you've been were shitty, maybe the problem is on your side. And if you always end up with the bad manager, it may also be that, with your attitude, you are not worth the time of a good one (or not, but at least do not exclude this possibility just because you dislike it)