Most projects that use a template based approach to layout end up looking like this. The example in the article is relatively straightforward, in my experience. Things get even uglier when your hot AJAXy javascript gets tossed into the template.
We ended up here because for the past 10 years the imagined process for web app development was that you had a programmer working on the "back end" and this back end spit out stuff to some templates, which a "web designer" could modify when you wanted to change the look and feel. Rails is a project started by people coming from the web design world, so the default approach is to use the typical division between back end and templates.
The workflow which splits things into back end + html templates, with differently skilled people productively contributing to each side of the app doesn't exist in reality. You'll eventually need some logic in the template. The web designers don't want to modify a template filled with logic, so what happens is the programming team gets "wireframes" from the designers, and then modify the templates themselves.
If you're a programmer, and you prefer to generate your html programatically, there are many tools that do this. A few have been mentioned already: seaside, markaby. This approach is great if the programmers have control over the development process from the back end to the front end. However, if you are working with an existing team, you've got 10 years of process inertia fighting against you. Thus, as is the usual answer on Hacker News, your best bet is to start your own company where you can apply the tools and processes with which you are most effective.
One advantage to the tag soup approach is that you can just take the templates the designer gives you. Usually they have been created with some WYSWG-software like dreamweaver and contain hundreds of nested tables and divs. Translating all that to a completely different language would be a nightmare. Much easier to identify the parts you have to manipulate programmatically and leave the rest of the code alone...
(This goes mostly for client projects, for my own projects I might have other standards. Although in fact for my moon calendar web site, I ended up doing the same).
The traditional view is that HTML is a messy presentational format with lots of repeated boilerplate and lots of subtle gotchas in the syntax.
In that view, it makes sense to separate HTML from the logic into templates, where the markup is basically handled as opaque strings by the template engine.
However, with semantic markup, each HTML element actually have a functional significance. The HTML is now the model, not the view.
This does not solve the labor division problem you describe, rater it turns it into a completely different problem. Now HTML is basically the domain of the programmers, and CSS (and perhaps some amount of XSLT) is the domain of the web designer. It it still not clear to me how these should work together.
We ended up here because for the past 10 years the imagined process for web app development was that you had a programmer working on the "back end" and this back end spit out stuff to some templates, which a "web designer" could modify when you wanted to change the look and feel. Rails is a project started by people coming from the web design world, so the default approach is to use the typical division between back end and templates.
The workflow which splits things into back end + html templates, with differently skilled people productively contributing to each side of the app doesn't exist in reality. You'll eventually need some logic in the template. The web designers don't want to modify a template filled with logic, so what happens is the programming team gets "wireframes" from the designers, and then modify the templates themselves.
If you're a programmer, and you prefer to generate your html programatically, there are many tools that do this. A few have been mentioned already: seaside, markaby. This approach is great if the programmers have control over the development process from the back end to the front end. However, if you are working with an existing team, you've got 10 years of process inertia fighting against you. Thus, as is the usual answer on Hacker News, your best bet is to start your own company where you can apply the tools and processes with which you are most effective.