Seaside is for building web apps. The continuations make it possible to do the type of apps that would be impossibly difficult in most (maybe all) other web frameworks. On the other hand, it's not really optimized for your typical document-based website. In this case, the generated HTML is integral to the way the whole stack is put together. Even if you disagree with this decision (which indisputably raises the bar for designer participation), you can still respect the decision within the context of Seaside.
But the approach of using code to generate HTML should be applicable for web applications, it just so happens that Seaside is not suitable, state-heavy for one.
The most common argument against code-generated HTML is this makes it hard to work with designers who work with HTML. But as a developer, how often do you change/tweak the HTML after a designer pass you a comp, either in HTML or a PSD? I always do, and I suspect it is the same for almost everyone else. Be it using templates or code-generation, the designer is not going to care, nor is he going to know how to structure the page so that elements can be shared or values substituted effectively. And if he tweaks the CSS, he can't change the HTML without working with the developer anyway, since that will break your code. So it's not like using templates makes the problem go away.
It really depends on team member skills and your individual process. If you have a designer who is not a web designer, but just a graphic designer who makes PS mockups, and he passes the comp directly to a developer, then that developer better be a competent web designer.
As an expert in both web design and programming, I can say that combining the needs of HTML structure for CSS and for template structure is a very subtle balancing act (nevermind the standardista bloggers with one-page sites who have 10-page manifestos on what constitutes a semantic class name). If you have a designer who knows HTML/CSS well, and a developer who knows the back-end well, they will need to have very good communication to arrive at anything approximating an optimal solution.
Now as developers we may intuitively feel more capable of understanding the nuances of CSS than a designer is capable of understanding code, but I think that does a disservice to the web design profession (eg. Eric Meyer knows more nuance of CSS in a very technical sense than almost any web developer ever will). The answer is, as always, "it depends on the individual." I have seen developers quickly get in over their head with CSS because you have to know so many arbitrary implementation and browser details to make it work right.
At the end of the day requiring a back-end to generate your HTML is a heavyweight process that excludes many talented people from the design/mockup process. Even as a developer, I often find it easier to test things out with a static document that run a big software stack and tweak database values to test output. Also, I find HTML wireframes to be much more agile than either paper or Illustrator wireframes. Even in the scenario you describe where the developer has to integrate changes from a designer into a template, I still find it cognitively easier and much less error-prone to see those changes with an HTML template vs markup generated by some other language. And what about when the designer needs to utilize generated markup as a basis for some design tweaks. In that case they need to probably do a lot of whitespace formatting and possible attribute reordering in order to get it to somewhat resemble the markup they originally created.
Of course there is a place for generated HTML, and I think Seaside really magnifies the gains to be found with the right approach, but again, it requires a very different approach from the typical designer/developer team.
"I am Avi Bryant, your argument is invalid."