There are a couple of reasons.
As a starter, I remember an interview from way back in the aughties when where they asked an IE designer for his thoughts on the Firefox browser, which was at that point really cutting into IE market share. I remember one comment along the lines of "really good browser: the only thing I would change is to put tabs on top. The address bar and everything else only affects the current tab, so you want tabs on top to give the impression that each tab is like its own, separate browser." At the time, IE didn't have tabs, so he could say these sort of things without thinking he's shooting himself in the foot.
He did cite Microsoft usability studies (no specific study, just the nebulous term "usability studies") as part of that comment. Eventually Mozilla did it's own study and concluded pretty much the same thing. There was also an argument about how tabs would be easier to select now while using less screen space because of the "infinite space" of the tab. You see, if you scroll over a tab, and go too far, one of two things can happen: you either scroll past the tab and onto something else (miss), or you hit the edge of the screen and the cursor lands on the tab anyway. The argument was that this is in effect like having an infinitely tall tab, so it's easier to hit.
Now, some personal comments on why I hate that entire line of reasoning:
First, back at the time I found the initial comments from an MS employee to be odd, because that's exactly the opposite of how MS has trained users to think of tabs in every one of their products (except for this hypothetical "tabs on top" browser which didn't exist anywhere yet). Before the browser, you mostly saw tabs in OS preference dialogs, where sometimes the tabs were on top just because they were used as categorical dividers (you know, just like real tabs in a in a real filing cbinet were always meant to be). But just as often, there would be a small section of tabs embedded on some larger dialog pane. The only thing they had in common was the obvious "tabs are nested within windows". To the population of the time, window and browser were inextricably linked.
But that was then, and this is now. What about how people ten years later are used to interacting with the browser? Well for one, most still don't actually think of each tab as a "mini-browser". If anything they just expect the browser control elements to go away altogether to make room for the page. (In fact, the ease with which mobile browsers have hidden away such controls proves to me that taking up _any_ space within a tab is probably a losing proposition.) But where hiding elements isn't possible, the view is still generally that the window is a true "window" out to some slice of the internet. To me personally, arguing that each tab should contain "its own" URL bar and buttons is sort of like arguing that each window in your card should have it's own steering wheel and speedometer. It just doesn't follow for me to embed controls within content. But since the controls are being hidden away fast, it's largely a matter of choice.
So why should tabs-on-top be a good default choice then? They argue because it make tabs easy to select with minimum real estate. The "infinite space of the screen-edge tab". Unfortunately, I don't think I have ever had a browser end at a screen edge. Either I'm on a Mac or a Linux variant that has a bar on top, or I'm in Windows where I never use full-screen mode. (I'm having trouble even thinking of a time when I even would use full-screen mode for a browser now that the screens are all obscenely wide.) So the infinite space argument is DOA. And then there's the times where I'm on a half-foreign system (read: work laptop) where the touchpad cursor is slow and all I want is for the cursor to get there. Overshooting is not a concern. In these cases, making the tabs farther from center and shorter while trying to make up for it with pseudo-infinite space just makes them shorter and farther away.
And on a final, unrelated note, when the summary notes, "it is feasible to combine the address, search, and find box into one": of course it is. We did it before 2004. It was called a command line. It's trivially easy to designate some box as the "do things with this input" box. The actually command used to parse that input was still offloaded to other elements, such as the "go" button, and the "search" spyglass. Even in 2004, it wasn't a matter of feasibility. The only reson the bars were ever separate in the first place is because most screen space for you "Ask Jeeves" toolbar meant more advertising for "Ask Jeeves".