I've landed solidly in "always reset" territory. There are just so many inconsistencies between browsers/platforms that I'd rather have everything looking as consistent as possible, and work from there. It does add extra garbage to Firebug, but it's worth not having to debug a display issue on a browser on a platform that I don't have access to.
There are only few differences that could break layout.
Hard problems are caused by different interpretation of applied styles, not because of defaults.
In case of form elements (which are underspecified in CSS), touching their style can make inconsistencies worse (different browsers use different box model for form elements, and achieve similar size with browser-specific defaults).
My biggest gripe with form elements is when sites (and browsers) expect the default to be black text on a white background, and change the foreground text to a near-black color. This wreaks havoc on systems with a dark colorscheme, where system input boxes have white text on a black background. This is the sole reason why I no longer use light-on-dark colorschemes, which I find much more pleasing, on my desktop (and laptop).
I avoid CSS resets because it makes it more difficult to work with the styles in Firebug. Because most resets apply to every element, if you've selected an element five levels deep, you're going to see five copies of the reset in the style list. And if that element is inheriting from other non-reset styles up the tree, they're going to be buried in the middle of those extraneous copies of the reset. That's a lot of noise added to what should be a simple, straightforward list of the styles that apply to the element you've selected.
I use Richard Clark's CSS Reset paired with my custom-built scaffolding CSS stylesheet. It rips out all the base styles applied by browsers, and builds them back up so that absolutely everything: fonts, form elements, tables, code blocks, etc not only all look identical in every browser, but are easy on the eyes.
I find it pretty laughable that developers ignore Resets because of a little extra noise in their CSS debuggers. That's like advocating against using a framework for another language because your stack traces are a little longer by default. In Chrome's Dev Tools you can hover over any final computed style to determine exactly what file and line it came from, and the rules are shown most-specific first. I rarely if ever have to scroll down to the broader rules where the duplicated Reset noise tends to be more prominent. I haven't used Firebug in a year or two, but I'm assuming it has similar developer-friendly functionality.
It seems more like those who categorically argue you should avoid frameworks, because hand-crafted code is going to be faster.
Which is about the only concrete benefit I see to avoiding resets. I'm probably going to tweak about the same number of properties, and the defaults are saner.
My personal technique is to start with a slightly simplified version of Meyer's reset. Then as I get to final QA I comment out each reset selector and see what happens.
It kind of gives me a happy place between using them and not.
I don't use pre-built resets, partly because they didn't exist when I started doing web development, but mostly because I'm not pursuing "pixel perfection". Ironing out tiny cross-browser issues is the very last step for me, after having dealt with content, usability, accessibility, maintainability, and performance.
There are good arguments for both but I've tended to agree with Yahoo's approach to YUI, which includes a reset. Not because I've explored it in detail, but because I figure Y! has (and at a large scale).
The second I learned this trick, many years ago, I've used it in everything. The argument that it's "slow" is ridiculous. It's like using while(i--) instead of a for() to shave 0.0000001 milliseconds off your javascript loops. Just admit you have OCD and move on ;)
I'm fairly disinclined to trust web designers on browser rendering performance issues anyway. If it were that big a deal it would be in CSS optimization code somewhere, but it clearly isn't.
