pay for time is just as "bad" to the client as fixed cost for the dev. The root problem isn't with the way the payment is made, but with the way one party's expectation does not match reality (whether it's the dev's or the client's).
I disagree with you on both models being equally bad, or prone to going bad at the same statistically rate. In my experience, as well as the reported experience of many senior programmers/consultants/freelancers/ISV's I trust, the pay-for-time (honestly worked, of course) is the model that's the least likely to explode on either party. And, surprise surprise, that's also closer to how the traditional direct employment (FT, PT, salary, wage, whatever) model also works. And in general terms, both sides always have the "escape hatch" of being able to fire the other party (speaking in general, with the caveat of arbitrary laws per jurisdiction, blah blah blah.) But in general, if one party isn't happy, they can vote with their feet. That's always true in life, in the general case.
But paying for hours/days means the worker is paid in proportion to how much work is involved, whether planned or surprises along the way. And the pay-per-time rate allows the worker to set a value that reflects the quality of his work, his productivity, or his rarity in the marketplace, or total demand for his time, etc. Win and win.
Fixed price, fixed scope is like... an unstable equilibrium. Trying to balance a chainsaw on your pinky finger. It can work out just fine. But that's not the way to bet, and to be avoided if you'd like to retain all your body parts.
Fix that, and any payment model will work.