Thinking as a founder/hacker - it's totally fine. Fixing those errors would have no effect on the user experience. There are no viewers that aren't using the site because of those errors. Fixing them would take time that can be more valuably spent elsewhere.
Be generous in what you accept, strict in what you provide.
Without that general principle the internet would never have got working. Even now, "standards" shift, and it's important that older sites don't simply stop working because of things that were once perfectly valid becoming slightly out-of-fashion.
Complexity is like a dead cat under the carpet. You can push it around all you like, but it will still be there, and someone still needs to deal with it.
It's just a shame that after a while it starts to smell, and the smell is hard to get rid of.
So true. Imagine the dead cats under the rugs that we entrust our lives to every day... traffic lights, onboard computers, flight navigation software. Anyone seasoned in software knows that the point is not to write bugfree software but to understand what your code is doing and how it's impacting things across the whole system. Code is very very complex and bugs can be introduced from compilers, third part libraries, yourself, system upgrades, hardware issues, etc.
If browsers didn't have to accept faulty pages, they would probably much much smaller, less complex and more efficient.
But we moved all this complexity into browsers. So only the few browser manufacturers are in need of highly skilled devs and the rest of the world can stick with "us" ;)
Many of the pages on w3c.org's own site do not validate completely. The front page validates as XHTML strict, but the other pages linked to from it have errors and are supposed to be HTML5 according to the doctype.
Some of the "errors" you point out are only barely even errors, like missing `alt` attributes (nice for accessibility, not so helpful when the image isn't actually content).
Others like using empty trs for spacing is just old-school HTML wrangling. Could it be improved? Sure. Does it actually matter? Only barely.
Many of the errors are dupes; if you roll them up there are significantly fewer "errors". Which makes sense, because the HTML on HN is trivial to begin with, by design.
Making a website compliant is like manufacturing your product with twice the precision necessary - for no reason whatsoever. But it's fun - if you're a masochist.
Why aren't you complaining that you checked against HTML 4.01 Transitional rather than 5, or 6, or whatever version you cutting edge people demand? You could then jack it up to 144 errors!
fun fact: pg hand-wrote the (original) news.yc http server (in arc) and it wasn't standards compliant. it terminated newlines with '\n' instead of '\r\n' causing much pain when trying to integrate any external tools. but, browsers accepted it, so it wasn't worth fixing.
Plus, let's ignore the whole "we only learned HTML in 1995 and never looked modern practices again" thing too because, well, it still works. Sometimes it's worth spending 5 hours making something just work using what you know instead of spending 500 hours making something ideologically pure.
HTML is a document markup language, not a programming language. There's no reason the site should not work in the case of markup not meeting strict standards, certainly not for the errors listed.
Also, it's not even really 66 errors - it's mostly the same three errors repeated over and over (no alt tag for images, adding a div inside a center tag and something to do with the end tag for table row.)
Although, there is also no reason for HN not to conform to standards.