It's small usability issues more than anything specifically missing. Some things off the top of my head:
* The "point to find in DOM" icon is tiny and squeezed in between other icons at the bottom of the page. It's one of the most important tools, imho, and it can't be tucked away like that. And it needs a keyboard shortcut to toggle it.
* The "point to find in DOM" is very flickery and just feels more shoddy than Firebug's. Firebug uses a rectangular border, which I think makes more sense than a colour overlay which obscures the content.
* The DOM tree view is gnarly; by which I meant that it's cramped, squeezed together, hard to edit and navigate, and just generally feels like one is fighting a jungle of vines and branches. It needs more spacing and more a consistent editing mode. Firebug's isn't great, either, but it's more spaceous.
* The CSS style view is also pretty gnarly in Chrome. The hit area for the checkbox to enable/disable a property is tiny, for example, and the overstrike is black, whereas Firefox wisely grays out disabled items. Chrome uses these dividers which are completely unnecessary given the source information on the right.
* The action to add a property is to click somewhere inside the CSS view that is not text. Yes, to click. It makes no sense, norwhere in any user interface do you add stuff by clicking in empty space. Firefox more wisely uses double-click, even if that's not great either, but at least has some precedence in GUI history.
* Chrome has no tools to add styles. Firefox has a right-click context menu for CSS properties allowing me to right-click somewhere and select "New property" or "Add rule".
* Chrome: The icons in the lower bar change depending on which tab (Element, Resources etc.) you're in. Pretty confusing since some of the icons apply to the tab you're in, and some are always enabled (like the "point to find in DOM" button).
* Firebug shows in this case all the CSS information I need for the element. Chrome is information-poor in comparison.
* Chrome has inserted a useless "element.style" entry which is unnecessary unless you actually want to add style to the element; for inspection purposes it's superfluous.
* Chrome also wastes a whole line for the "computed style" part, which Firebug wisely tucks away in a tab.
* Chrome wastes the whole lower line on the DOM path, which I personally never use. In Firebug it's part of the DOM view and doesn't affect the CSS view.
Here's an improvement suggestion I'm surprised nobody has thought properly about. One thing I often need to debug is the flow between pages. For example, in some web app I click a "Login" link, get a login page where I edit stuff, then click "Log in", then the server does a few redirects and finally gets me to the "you're logged in" page. Now, Firebug and Chrome both have a "persist" mode for the network view which allows one to see the sequence of pages being requested, but since it's a strict log and mixes different content it's very hard to read, and very hard to figure out the true flow of events from. Here is such an exchange: http://i.imgur.com/aCs8pmF.png. To get it I had to select the "Document" and "Other" event types. But I have to spend 10x as much time analyzing this than if I simply go to Firefox and turn on the stupid but effective "Live HTTP Headers" add-on and then copy everything into a text editor. The HAR is too cooked to give me a proper bird's eye view.
Truly what I wish for is some kind of graph that's page-oriented. Here is a very quick Illustrator mockup: http://i.imgur.com/pQqOtPX.png. Obviously hovering/clicking on various elements would let you look at headers and what not. The idea is really a persistent timeline with a certain history, and which presents a logical view of browser navigation. It's important here to distinguish between user actions and stuff done by the browser (redirection, AJAX); it's important to know when something contributed to a page render or was just one link in a chain of redirects.
Again, I could go on, but I have better things to spend my evening on. :-)
