I agree with your first post.
But I disagree with the second one.
Readability is one thing. A goal that anybody have to reach. Nobody will complain that things are too readable.
But Direct Access to tools and properties is another goal to reach. Nobody will complain that UI is too fast.
If you don’t have to scroll and open a panel and subpanel to click on a value, but just to click on displayed value : you are working faster. It is not more complicated to understand.
So complaints about not being able to display lots of properties is as valid as complaints about unreadable settings.
You can not set properties in Blender and texts in web-browsers on same level.
Reading text is main business you have with a text. A text is ordered to be scanned from left to right, from top to bottom. Text is the reason why scrolling exists.
But it does not changed the fact that organizing a text into columns have always been considered as a help to read it efficiently.
Grouping of properties is done to be meaningful.
But having settings next to each over does not make a sentence.
Scrolling a properties editor from top to bottom does not develop a thesis or tell a story.
And when you are writing a text, you don’t scroll. You are using shortcuts to find occurrences of a word, to jump to previous/next word, to jump to a specific line, to jump to previous/next paragraph, to jump to a specific page…
You are also going back and forth when you are editing properties. You are not setting all values in one panel and then set-up next one and go-on like that.
So, in absence of shortcuts to cycle through panels, to call on top of editor a specific one, UI is slow.
And no matter how many shortcuts are added to properties editor.
Nothing will be faster for a specific task than having all required properties for it, directly accessible.
I am not against single column layout readability.
I am against the misconception that user need to read a label of a property to modify it.
If he creates a workspace and get used to it, having a property at a specific position of screen will become an habit like placement of keys on a keyboard.
I am not against subpanels and grid layout.
I am against the misconception that solves the problem for dense properties tabs. It does not.
Subpanels are adding a row per subpanel header, potentially taking away others interesting panels.
And it adds a click reducing direct access to settings.
Grid layout is not taking into account panels headers rows. It is making ridiculously stretched panels, made of 2 or 3 rows, between panels made of an arbitrary number of columns. It is less readable and less efficient than columns of panels using single column layout. This fact have nothing to do with the unfinished state of the feature. It is related to the concept of monopolizing a whole row of a large properties editor for a panel header. That is a waste of space.
It is the reason why User Preferences UI is just one panel with an hidden header and tabs in it.
If Tabs in User Preferences window would be panels, you will be complaining about an unbearable scrolling in this window like anybody.
I will concede that maybe we may need to think more about how we might be forcing to much into a single tab. We might simply need more tabs or a better arrangement of data in the tabs we have.
In my opinion, adding tabs with panels is not a solution. It adds one click to split same area of interest without removing other panels and subpanels extra-clicks.
I think that having an alternative floating window for render tab organized in 3 tabs (output/performance-quality/post-processing) and several columns like preferences would be more efficient.
Mock-up is not perfectly aligned. It is less readable but not unreadable. But access to many more settings is quicker, more direct.
A dedicating window for particles could probably benefit of some kind of layout 3 tabs (physics/display/textures-vertex groups) with several columns in each.