People want to configure layouts that match what we find in Web UI for their custom doctypes.
They tend to keep things close to whatever default we provide because:
It gives a feeling of consistency.
It's less work to just adapt something that exists and their time is limited
It's a best practice to respect how the app behaves in the first place, and maybe tweak it slightly to adapt to your own needs, if you want to maintain it more easily.
Currently they don't have any way to reproduce what Web UI provides. So as a workaround they just override default document types (bad practice) in order to get something that looks closer to Web UI default configuration faster. That happens typically for demos and pocs, but since people buy the product based on what they see at this stage, two things can happen:
They buy the product, expecting to reproduce that experience easily => that impacts the dev experience and time to market
They dig deeper, and raise concerns about the actual feasibility of this experience => that impacts the sales process
Reproducing the whole Web UI look easily is what we're providing with visual page configuration overall. At this stage what we want to deal with is just a subset: making sure that result looks consistent with Web UI when inheriting from default document types / your custom doctype.