Developers are often being paid to do things they've never done before and, as such, it's hard to do anything but bill hourly. Offering a fixed rate and having to eat hours to meet it isn't fun.
I've found the best solution on my end is simply to first try to estimate a little pessimistically, and then to charge enough that I'll feel fine even if the project takes me a couple days longer than I thought. If a totally unexpected pitfall appears, a reasonable client will be open to renegotiating.
It's so worth it just to avoid the not-so-goodwill that seems to accompany hourly billing so often.
Specifically, it means you now need a far more detailed requirements doc BEFORE you can start working (safely, anyway), and you need to manage changes much more carefully because they are coming directly out of your pocket.
Plus, as an hourly guy, I never cared when the customer wasted my time, e.g. with over-attended phone meetings that take unnecessarily long because everyone needs to have their say. It didn't matter, because I was paid for it.
I charge precisely for my time worked (love Desktop Task Timer, BTW).
I am lucky in the sense that almost all of my customers are themselves very good techies, and when I work remotely we use Skype calls and instant messaging throughout the day: lots of communication and brain-storming. Since I live in a remote area and my local friends are non-technical, these calls tend to be fun for me.
Most of my customers don't even bother asking for time estimates.
Bottom line: I get a lot of pleasure working and helping people and my customers at least seem like they don't mind paying me.
I don't know enough about developers and per-hour billing, but in my view, consultants need to move away from this model to more transparent models that directly reflect what they can bring to the client.