I think (If I'm reading your questions right) that's what the other respondents are missing here -- you seem to be asking why these inconsistencies even exist in the first place.
When it comes to HTML, that's actually very simple if you know what HTML was designed FOR. HTML was not designed to create the appearance of a page, it was designed to mark up content so that the user agent (aka browser) could best determine how to show it on target hardware. The very notion of having the same HTML appear the same in all browsers runs entirely against the basic concept of what HTML is FOR. This is why the HTML specification is filled with "may" or "could" or "typically" -- but you'll be hard pressed to find a whole lot of "should" or "must". Take line-height for example where it "suggests" that user agents "typically should" use a value somewhere between 110% to 130%... Things like default paddings, margins, font sizes -- that's all left to the discretion of the user agent so that the content (the actual important part of the page) can be best delivered and/or customized for whatever hardware you try to show it on -- be it a 22x20 VIC=20 display, a plaintext only teletype or daisy wheel printer, right through to todays 2560x1536 displays. This is why semantic markup is how it's supposed to be written -- saying what things ARE, NOT how they should appear... hence my constantly saying "if you choose tags based on the default appearance, you're probably choosing the wrong tags".
HTML got away from that with HTML 3.2 as many people making pages started to give a flying fig about anything except 800x600 or larger screen -- during the browser wars the various browser makers started making custom tags JUST for that type of target and 3.2 adopted many of them... This basically pissed all over accessibility and since they started out as proprietary tags, they only worked in certain browsers.
To address this CSS was introduced -- and that's where things started to go to hell... since so many browsers had different default paddings, margins and sizes on elements adding CSS into the mix meant you couldn't trust the defaults to be the same. In many cases (INPUT comes to mine) you couldn't even apply styling consistently just because Netscape and IE had different default paddings that were separate from the padding CSS declared. (a problem that plagues us to this day!).
Though MOST of the cross-browser issues we face today come from one source - IE... which in version 5, 5.2, 5.5 and 6 were all the most standards compliant browsers of the day -- and that's actually THE PROBLEM. They were implementing standards that were in draft (CSS2) and because it was so useful, developers started deploying websites in it before the specifications were finalized. Because the specs changed you ended up having the box model issue and the doctype trigger in IE6 to try and say "pages that don't have this probably use the old box model". The CSS specification is also very vague on the application of CSS to elements, in particular to this day things like form elements are a royal pain... The browser makers are often forced to make the choice -- do we fix this so it works as the specification says, or do we leave it alone or add some sort of trigger so the pages made over the past decade don't break?
Again, take INPUT as an example -- Trident and Gecko both treat INPUT as a 'special' tag that has a default extra padding you have no control over -- one browser declares it it EM, the other declares it in PX (I forgot which is which) and this padding does NOT go away even if you say padding:0;... Both browsers treat them as "special" regardless of if you set display:inline, display:inline-block or display:block. Worse, FF obeys height and ignores line-height on them, while IE ignores height and uses line-height -- the specification? DOESN'T SAY WHICH IS CORRECT!!! You get Opera in the mix and it SHOCK treats them as inline-block or block EXACTLY, meaning height works, line-height will work if height is set to auto, and there's no extra padding apart from what you declare...
... and don't even get me STARTED about Webkit and form elements.
Even more idiotic when you figure in browser engines like gecko adding the HTML 5/CSS3 stuff when they have gaping holes in their HTML 4/CSS2 implementations that just became teenagers. -- part of why unlike other developers I actually applauded Microsoft for NOT trying to add CSS3 stuff to IE8 -- as maybe they should focus on getting HTML 4/CSS2 working better BEFORE moving on to it? Part of why 9 is so disappointing as sure it adds some of the flashy CSS3 crap, but it's still nowhere near correct for HTML 4 and CSS 2!
But that's browser development in a nutshell -- if it's not flashy and trendy, kiss off it ever being fixed... and worse that's usually twenty times worse on open source projects... See bugzilla 915, Webkits handling of CAPTION, etc, etc... documented bugs that are anywhere from 8 years to 13 years old and remain unresolved in open source projects... making the complaints about a browser that went six years without a development team seem kinda lame.