I have one proposal and one thing to consider
The proposal is that, since I miss having a bar to click Commands directly, and now they’re all in menus, I’ve been considering for a time for a way to automate the process of making panels with command buttons. But the solution became clearer over time and you guys have thought of it already. If we go on the customization route, then the solution would be that every Panel can be a menu/popover, and every Menu can be a Panel. There’s a software that kind of does this already. Zbrush. All the menus on the top are more like popovers in the sense that they contain properties as well, and you can drag any of those menus to the sidebar and have it expand like panels in Blender. Blender could go on that route but with more granularity even. You could drag a menu, a submenu or a popover into the sidebar, and it would become either a tab or a panel, with more panels or subpanels, or not. Or you could grab a tab or panel from the sidebar and put it in the header, and it would then become a menu/popover, maybe with nested menus, or not. Or the whole sidebar could be put sideways with the click of a button and become an extra header with a row of menus, or viceversa, click a special button on the header and it flips vertically and with some width to reveal tabs and panels. What about going smaller? You could move individual properties over to a header and create your own topbar style bar. Just some random ideas on how it could be done. But yeah, that’s the idea. Panels = Menus, Menus = Panels
The thing to consider is that, we need to question up to what degree separating Commands from Properties from Tools is a good thing. We need to question the priority of data structure over workflow proximity when it comes UI design. Maybe it’s ok to have a Command and a Property together if they relate somehow.
I’m sure you guys have noticed if you follow development and discussions closely, but developers tend to favor separating things in terms of the place they’re stored or what they are. I’ll give you the opposite example that confirms the rule. If you go to the Shading popover in Solid shading mode, you’ll see that Shadow has a little gear icon. The properties inside that gear are stored per scene, but it took a lot of convincing for the developers to put that gear close to the shadow toggle despite the fact that they are closely related, only because they are properties stored per Scene and not per Viewport like everything else in the Shading popover. Because of this, you’ve seen things like the disappearance of the Render button, or the Object Data tab being further from the Object tab. Obviously, it can’t go fully far, there’s a limit on how much you can forego practicallity for the sake of logic, there are many examples of commands in the Properties Area, like the Bake buttons in many simulations, or the Disconnect hair button. Of course that separating properties from commands was a good thing. It was a mess in 2.49 and then it was decided in 2.5 to separate them. But, to what extent can it go? Even now, I’m battling over the removal of the Lookdev shading mode for 2.81 because developers seem to prefer structure over usability.
Customization would again be part of the solution for this. The structured approach to UI design of the developers could be used for the new user to understand the structure of Blender, then they can move those things around as they please, after having learned where a property comes from.
Another alternative could be some kind of visual feedback or visual indication that, despite two properties/commands being relatively close together, they belong to different places. To the scene, to the view, to the object, etc.