Product first, then polish.
Get your site/application/game doing what it's supposed to do. Get it up and running, and get people interested.
Then, when you have the time, go back and polish it up. But only because you care, not because anybody else does.
Of course, if the non-compliance issues mean people can't view it, or it's unreadably ugly, or it takes a month to load, or it's hard to maintain, or it crashes the browser, this is a major problem. But it would still be a major problem even if you were standards-compliant.
Ordinary users do not look at the source for a website that isn't loading and go, "Well, it's not displaying the pictures, but it's completely W3C-compliant". They simply browse to another website and never return.
Bottom line, standards are there to make writing browsers easier, and to close up potential security holes. Amazon, Penny-Arcade and Stack Overflow do not make their money from running a standard-compliant website. And unless you're in a website-writing competition, neither will you.
The choice whether to include padding and border into the width or not was arbitrary. The only thing where it mattered was building multi-column layouts. However, you should pay into account the fact that people used tables for layouts at that time anyway. So to them that concern didn't seem important enough and they considered that being able to specify the exact width that the content itself would occupy in CSS seemed a lot more valuable.
For today's developers the situation seem totally different as they use CSS for layouts and they have to deal with CSS boxing model. Thankfully we've got an ability to override boxing rules so in most cases simple rule at the top of your stylesheet works fabulously:
* {
-mox-box-sizing: border-box;
box-sizing: border-box;
}
To quote Jeff Kaufman on the subject:
Given that the spec defined it the other way, though, the signal it would have sent to Microsoft to adopt their misinterpretation would have been bad for the web. Microsoft was already using an embrace, extend, and extinguish approach, where they intentionally made products that acted differently from competitors' in order to lock users into the Microsoft versions. They came very close to succeeding with the web: from approximately 2000 to 2005 IE was so popular that many sites designed just for it. Adopting IE's approach here then might have told Microsoft "you can do whatever you want with IE and we'll adjust the standards to make it legal".
So box model fell the victim of power-struggling between W3C and Microsoft.
Best Answer
The fluid layout provides, in general, better user experience, but is not without flaws. When using fluid layouts, you are testing them on medium-small to medium-large screens, but you certainly can't do complicated fluid layouts with CSS2 (no JavaScript, no HTML5/CSS3) which works perfectly well on any device, from a small mobile phone to a 30-inches full-screen mode.
The fluid layout is also more expensive in most cases. This is true for the visual design, the ergonomics and the HTML/CSS development.
The fixed layout gives the ability for a developer to say:
I gathered the statistics about the browsers of my visitors, and know that 95% of users of my website have a resolution width between 1024 and 1920 pixels. Instead of spending a month designing a fluid layout, I will target the resolution of my 95% of users, and spend the free time to implement some cool features instead.
If I have enough time and resources, I'll do a dedicated version for mobile phones.
The fact that fixed layouts are easier to implement is important here. I have a choice: either I do a fluid layout which will in all cases look bad on very small or very large screens, or I spend the same amount of time and money creating two or three layouts for different resolutions.
Aside the cost, fluid layouts have also some issues you can't solve without HTML5/CSS3 or JavaScript.
Example 1: Programmers.SE has a fixed layout. This means that on any resolution, the main text I read (the questions and the answers) will be no longer than, say, 800 pixels in width. Given the current font size and the line spacing, this is ok to be able to read fast.
If Programmers.SE moves to fluid layout, your current question would we 1 600 pixels width on my screen at this moment. This will be totally unusable, and I wouldn't be able to read a long text without requiring to minimize the browser window and adjust it for the website.
Example 2: in a recent project, I split the text in two columns for the browsers which support this. Given the font size and the line spacing, one column is not really readable, but two are perfect. Since I know the width of the page, I know how the text will appear in 93 to 94% cases: the other 5% are using browsers that don't support text columns, and the final 1 to 2% are using custom font sizes (i.e. people who don't see well and enlarge the fonts by default and/or people who don't have the font I use on the page).
With a fluid layout, I wouldn't be able to do that without HTML5: on a 30-inches monitor full-screen, two columns would still be unreadable: it would require four or five columns instead. On a screen of a large mobile phone, two columns would be unreadable neither, since there will be one to three words per line.
Example 3: you have a topmost menu with the parts of your website. There are five parts, and the elements are
float:lefted. With a fixed layout, it magically works, and fails if the user specifies the larger font for accessibility reason. With a fluid layout, what will happen with those elements if the user resizes the page to a width smaller than the total width of those five elements?