Whilst your response is amusing it just strikes me as so opposite the ethos of the site as to be simultaneously depressing.
Like having a car that leaks oil all around the engine compartment and have the manufacturer explain that this is fine as most passengers don't look in there. Then finding that a gasket alteration could fix it but the manufacturer isn't bothered because, well what's a bit of oil [bandwidth] and mess [sloppy markup] when the car still runs.
I don't know the system that the site runs on but assuming that the presentation layer is abstracted from the base logic it should be easy to fix at least some basics (doctype, font tags, gzip, etags, expire headers) even if one didn't go the whole hog and rip out the tables.
I'm not at all suggesting to alter the visual appearance incidentally I like the minimalist design.
A more accurate comparison would be using a compiler rather than writing machine language code by hand.
When computers first appeared, everyone wrote code in machine language. People thought that's what programs were. When the first compilers appeared, I'm sure a lot of people were grossed out by how ugly and inefficient their output was compared to the hand-written machine language code they were used to. But people who thought that were solving the wrong problem. What matters is how the code looks to the programmer writing it, not how it looks to the machine executing it.
People who think HTML should be elegant are making the same mistake. HTML is object code. What matters is the representation the programmer sees, which in this case is the source of HN, which is quite concise.
Your analogy appears to break down, and forgive me if my analysis is poor, when one considers the bandwidth.
Concerning oneself with HTML is different to fussing over optimising assembler in a regular computer because the mark-up is being pushed along many pipelines which are handling other data traffic, limiting the speed of data transfer limits processes involved in the presentation of the page.
I guess it's like optimising machine code to be run on a massively parallel computer in which real-time operation is desired.
In your analogy the compiler isn't [generally] producing the same assembly as if the code were hand-optimised. Clearly there's a play-off but if you could cut your transport across a data bus significantly with a couple of cheap and simple optimisations (either direct to the compiler or to it's output) then it's quite likely that you would, isn't it?
The main thing for me anyway was the surprise of finding this here. To add to my other poor analogy it's like going round to dinner at a famous chef's house and finding that they ordered the food in and just reheated it; just not what you expect. Sure you get a hot meal at the end of it, sure it might be nice, it's just you expected more.
