You might classify this as either an example of your "Funky" style or as a discrete fourth style:
4. Smarty style:
- Include plain-text markers (usually delimited by curly braces) for replaceable items in the template; interpret the entire template at run time, replacing markers with content. The process aims to be more designer friendly since programming constructs are not directly embedded. Whether you use Python or PHP or other server language, you'll parse and replace the placeholders the same way, so the template is relatively benign and reusable in that sense. Conversely, you generally give up being able to pass parameters to embedded functions.
However, you've asked a deeper question that I've also had to wrestle with, and have thoughts to offer: "What style of template system allows for fast development and a more concise design and implementation."
Since your are developing your own CMS, you have the freedom to define your own interfaces to the template system rather than adapting your interfaces to an existing system. You might consider:
Do you want to provide an API to other systems that will bypass your templates? In this case, at the point where you would ordinarily call your template, all of your content needs to be available as fully resolved endpoints for the remote API requests. As a result, your templates will generally be executable HTML files with variable calls that instance that same content into the appropriate places in the template.
Most API-driven applications will request the main content (title, author, body, page meta) but typically not the same inner-template parts like the sidebar or footer widgets as the web-based user experience. This is a good design approach for any CMS that provides fairly narrative or static content--that is, the content area of the web page can be easily pre-built as a chunk of content prior to being instanced into the template or sent as an API response. Templated content of this form tends to use category names as the labels for the primary tabs, since the main role of the web interface is to provide hierarchical drill-down into rich CMS content (encyclopedic or reading-oriented sites for example). The single index is fine in this case because there is no functional change from view to view, just content updates. Lends itself to front-controller type routing that ties into the content categories/hierarchies.
Does the CMS provide more of an application-based behavior? If the top-level navigation is instead switching from home page to forum to blog to admin, etc., then the "content" is probably very different in each template, and probably a series of functions/queries with headings rather than static content.
Here, you may either have a separate template wrapping each distinctive type of main content (forum vs blog vs static home page), or a single template with a function in the body that switches the instanced content. Either way, you can still serve that content as endpoints for API requests. This general CMS approach lends itself to page-controller type routing if using separate, type-dependent page templates, particularly if the template shell itself may need to be somewhat different for each content type. On the other hand, if you can implement the content switching via the single embedded function (which may need to control sidebar content if it contains context-dependent widgets), then you can still use the single index template approach which will give you more consistent look and feel experience for users. Either page controller or front controller routing can provide the resolution for that content switching--you are just using a common template with a parameterized content switch instead of a parameterized page with its own fixed content type.
If you can make a clean interface between the content that the CMS prepares in response to a query and the template system (or API call) that uses it, then you will have an additional advantage: By simply changing the name of the template directory, your same-named templates in the new directory will render the same content nearly equivalently. I think this is the single most important payoff of designing that content:template:api interface clearly--you end up with a richer outer template environment like Wordpress enjoys, your context-dependent regions like the sidebar and the footer can make use of inner templates for instancing content into the outer template like Drupal, and you can define the replacement mechanism as either a programming call or a parsed locator as your application requires. I'm able to take any free or commercial template and retrofit it with my CMS interfaces in fairly short order to support very different thematic styles. Most of the work ends up defining separate views between different themes that have their own inner styles for non-primary content (such as sidebar widgets or for the lists/tables used to represent collections; the main content usually just pours into its reserved area without intermediate processing).
Hoping this make sense for the CMS you are designing!