I came upon a paper Dynamic or batch publishing?, which was interesting in light of my recent post.

Here's some of the features James Robertson gives for dynamic sites:

Instant update. We do that too -- you change something, it gets immediately published. Not a big deal. I don't understand the author's concern with batch processing -- event-based static publishing works quite well and doesn't require batching.

Content on the site can be dynamically filtered based on the user, section of the site, or other rules. That is a real problem. We regenerate select pages (which contain embedded code) whenever a "related" page is changed (which is for most site updates), which allows us to create things like dynamically-generated navigation elements. User-specific dynamicism is out, though.

Navigation reflects the structure of the site from moment to moment, and 'related topics' are always up to date. No problem, using those "dynamic" pages (which are still published statically).

Dynamic publishing is also very well suited to personalisation and role-based customisation. Nope, just can't do it. Well, technically we could by publishing more code to the site, instead of plain HTML (actually with server-side includes, but that's an incredibly anemic scripting environment).

'In-context' editing. We do this, using a proxy that does a recursive fetch of the page, then adds a bar to the top with editing controls. This only applies to the development side of the site (which is what you'd want anyway). We use separate domains to avoid rewriting all the links (which is error-prone).

Versioning and 'back in time'. Versioning works fine, but viewing a branch or specific date of the page is not feasible. Because we are utilizing some features which are relatively opaque to us (Apache server side includes) we are somewhat tied to a static version of the site being present. Of course, we could easily reimplement SSIs in Python, and then be able to present the-site-as-it-was, instead of only the-site-as-it-will-be. I'm not sure if we'll see a demand for this, though. Branching and more sophisticated version control also remains outside of our domain, and probably outside of the sophistication of our users. Branching is not easy to use!

Blending sites. We do some of this, by controlling multiple sites off a single application (and database) instance. One "site" can provide content across sites, through a common interface and with shared internal tracking. Sites cannot be user-customized, though, so a single site cannot play multiple roles (e.g., one personality for the public, another for employees). These are two sides of the same coin. Personally I think cross-site flexibility is more useful than multiple personalities in a single site. Domains are cheap, and subdomains are free.

Actually, looking through the article, the CMS we've written would be a "hybrid", because of our use of SSI and the dynamicism of the development site.