You should be paid to do a fixed amount of work (generate a certain amount of value for your employer), not work a fixed number of hours. If you can get that work done in 10 hours a week, everybody wins. If you need to work 70 hours a week to do that work, well, maybe you're not a good fit for the job.
How do you consider the factor "good work"? You can finish a job quickly, but it'll bite you (or a coworker) in the ass later, or you can do the job well, but take you longer.
As a programmer, I can't thing of a worse way of management than the former. You'd have to start defining criteria for "good work", and then spend tons of time reviewing. Nightmare.
^I'm inclined to agree with you. There's definitely NOT an economy of scale when it comes to developer productivity. Sure, my company has some guys making $60K a year, but they certainly get a lot less than half or a third as much as the senior-level folks. I've got a lot more to say on this, perhaps a blog entry is in order.
I haven't heard of a company that lets you idle even if you produce an average employee's week output in a day.
The 'fixed amount of work' only works one way. You need 70 h to do it? Stay long hours. You did it in 20 hours? Well great, we'll just pile more work on you.
For a big company at least, I feel that this is an ideal world solution rather than a real world one. The amount of hours tasks take are going to be really hard to estimate, meaning that your work hours will on part depend on the luck of tasks allocated. Also you will have plenty of people out to game this by setting low expectations of what can be achieved in the week and making those in less hours.
The problem with that is measuring the amount of value you generate. For some jobs that's easy, like sales - and those jobs typically do pay based on the value generated (ie. commission), at least in part. But for software development and other knowledge worker jobs it's just about impossible.
