The first counter-point I would have to the approach you are describing, @AntoniDol, is practical in that what you are describing does not scale terribly well. Deferring the type assignment process to the very end may work okay if you have a few dozen binder items and a simple hierarchy, but it wouldn’t make much sense once you get over a hundred in an outline that has a fair amount of intended structure to it (like part - chapter - section - subsection, etc.).
The second issue I would have with this argument is that Section Types can be very useful in all phases of the project. I would view them as having a similar role in the outline as styles do to text. They are a way of bring structural clarity to the outline, and as such they are a form of metadata that can be useful in and of itself—no less useful than the Label or Status flags, for instance, in searches and so forth. I even use them for roles that do not particularly have to do with compiling, such as marking different kinds of notes. This is what is meant when we refer to Scrivener as a typed outliner, where nodes have semantic meaning—and to me that is just as if not more important than the label.
While that does not mean everyone should work that way, it does demonstrate how thinking of Types earlier in the process can be beneficial—much by the same argument that thinking about Styles during the writing process can be beneficial, even though we may not be considering what they look like until they compile. To my mind anyway, having no firm concept of what I’m writing into, as a structural point of detailing, would be difficult.
In short: there are good reasons why we made Section Types a fundamental part of the project, rather than being simply compile settings. Indeed if they had no role in the project, it probably would have been more straight-forward to dispense with Types entirely, and map Layouts directly to binder items (either through structural mappings right in the compiler, or manually).
As Katherine notes, the listing in the Contents tab of the compiler is, by design anyway, meant to be more of a reference than anything. It is a way of making sure that the Layout assignments you are making correlate properly with the outline. That you can edit them here is more of a “well, that would be nice to add to the design” thing, than meant to be the core interface where one does this. It’s a pretty bad place to be doing it, given you really have no way of knowing what is going on save but binder titles. The Outliner in the main editor is much better, as you can open items and make sure you remember it correctly, etc.
Theory stuff aside—as far as how people use Scrivener—I go so far as to say that by a very large percentage, most writers using Scrivener do not give much of a thought to Section Type assignments in any sense at all, least of all to the degree of manually making assignments one by one. Most will start using Scrivener with one of the built-in templates, which has an example hierarchical setup that works well most of the time, and has simple instructions in its help file to switch things up if you prefer another way of working (like chapter-length files instead of folders with multiple sections or scenes).
About that, the amount of times I see people painfully coercing their writings into an uncomfortable hierarchy just to suit the sample structure provided in the template is enough evidence to the fact that there are a lot of people that could make life easier for themselves by learning what they are. Logically and from a standpoint of efficiency and ease of use, there is no reason at all to have 25 folders, one for each chapter, each with one single file in it—except if one is not learning how to use Section Types and thinking they have to follow the “rules” as described in the Default Types by Structure tab.
Now does all of that mean the preview column should be second or last? I don’t know, I don’t actually have a really strong feeling on that—but where I do feel there is a good argument for having options on the right side, in the same sort of position that the inspector is in. The preview of the document, driven primarily by the adjacent Format list, makes sense in the middle especially once you click on other tabs on the right. At that point, I think it would be a little strange to have settings for metadata and such in the middle.