I tend to handle what you're describing with a separate channel for each major section - not that this is absolutely necessary mind you, but I do find it helps with the logic in template. When I combine it with stash add-on, it works wonders. Then, my template group index template has little other than the logic of what to show when that template is hit and passes the result of that logic into a wrapper template. It gives me a very high degree of control, while maintaining a very consistent experience for the site editor with everything being in channel entries accessible through the publish/edit screens. So for example, a "static" about section, as you describe would be handled like this, the way I've handled it:
1) Create a channel field group for static pages called "pages" (you could make this channel specific if you wish to allow for more separation of field approach between channels - sometimes I do, sometimes I don't)
2) Add custom fields to the field group, such as cf_pages_body (and any other fields you might need, such as seo fields, alt titles, etc)
3) Create a channel for static pages called "about" and assign it the pages field group and your default status group
4) Create a template group called "about"
5) Create a template group called "layouts"
6) In the layouts template group, create a wrapper template called ".inside" that contains all the wrapping html for the inside page - you can of course break that up further with snippets for a DRY approach to the template code itself
7) In the "about" group index template, you lay out your logic use stash:set to stash the results to parse into your ".inside" wrapper template
8) In the .inside wrapper template, you use stash:get to grab the stashed values associated with the accessed URL
So a very simplified version (stash has a lot of additional parameters you could use for performance, parsing priority, etc. that I'm not showing at all here) of the your logic template may be:
{embed="layouts/.inside"}
{exp:channel:entries channel="about" orderby="date" sort="desc" dynamic="yes" disable="whatever|you|can|disable" limit="1"}
{if no_results}{redirect="404"}{/if}
{exp:stash:set_list name="page_body"}
{stash:entry_title}{title}{/stash:entry_title}
{stash:entry_body}{cf_pages_body}{/stash:entry_body}
{/exp:stash:set_list}
{/exp:channel:entries}
In this example, I'm using stash:set_list tag pair to stash each custom field in a "list" in which each stashed element receives a name that is then called upon in the wrapper template to "get" and parse in place. For a simple example, this will do. It allows you to be a bit more DRY this way since you can avoid putting any formatting markup in there and instead handle that in the wrapper template.
Then in the inside template, you would get that stashed entry content (again, simplified):
<html>
<head>
{exp:stash:get_list name="page_body"}
<title>{entry_title} | {site_name}</title>
</head>
<body>
<h1>{entry_title}</h1>
{entry_body}
</body>
{/exp:stash:get_list}
</html>
When static content pages like this are handled as entries, you may also find value in using an add-on for entry ordering with this approach as well so there is a simple way to choose the order of static page entries. It would make more sense than ordering based on date or a custom ordering field in the field group that you can't see in the edit list view. Low Reorder is a good choice for this.
Important to note - naming conventions become a lot more important the more DRY you try to get - something to consider in order to plan an approach like this.
Hoping I haven't overlooked something in the example - going from memory to keep the concept a bit simpler than my actual implementation, so I'll correct if an issue is caught that I've missed. Hopefully this helps.
