HTML is object code only because you don't have a dedicated designer who wants to make design decisions and changes without requiring the programmer's time. For news.yc that's fine, but for many business sites, having HTML automatically generated in a designer-opaque manner is inconvenient. Eventually you want to hand off the design to someone who is good at design, and having to find someone good at design and good at the programming language you use limits the pool of designers.
The usual alternative to html-as-object-code is to use a template system, but template systems seem to move as a group (and individually during development) toward being a way to write your usual language, but surrounded by HTML, which has the same problems I outline above, since the designer still has to mess with what's really application code. I suppose this is because template systems are usually designed by programmers, for programmers.
You may notice if you look around that much of the time when someone replies to someone else (in any context, not specifically news.yc) they are saying something they wanted to say or like saying, rather than expecting to change someone's mind.
In fact, there are many, many exceptions to my general rule that you'd want to eventually turn over HTML/CSS/design stuff to a designer, and news.yc is one, probably. But the vast majority of my projects are no exception, and I'm fortunate to be married to a designer with strong opinions on the matter, so I get good feedback. :)
Heh. Actually, for most things I've been involved with, UI has been more difficult than any of the rest of it.
One of the promises of the web was that interface could be cleanly separated from the application itself, and it seems to me that most approaches being used today throw away that promise because the programmers assume that UI and design aren't important, or aren't hard.
So yeah, HTML is object code to PG because it can be. Sure, separating programming from web design may be necessary, but it's not better. Having the two concerns properly considered together is better, though more difficult to pull off.
The usual alternative to html-as-object-code is to use a template system, but template systems seem to move as a group (and individually during development) toward being a way to write your usual language, but surrounded by HTML, which has the same problems I outline above, since the designer still has to mess with what's really application code. I suppose this is because template systems are usually designed by programmers, for programmers.