This logic fails to account for priorities changing. If priorities change Friday morning it could mean all the work you did that week was worthless. Should one spend their whole weekend working to finish some deliverance or should it be limited by the expected hours? Similarly if someone front loaded 40 hours Monday through Friday and priorities change on Friday or a critical bug comes in people will have to wait until Monday.

If priorities are being made after code is written then it won't matter if the code took a day, a week or a month, or whether it was done under the company's florescents or a sunny back patio. Decisions about near-term objectives should be made before work is underway, or interleaved with experiment development and analysis.

Your last statement actually supports my point that it shouldn't be about hours served but about objectives met.

Admittedly, it is much more difficult to clearly define work expectations when they aren't in terms of hours, and doing so fairly across team members is especially difficult. And things like on-call rotations complicate that even further. But it's also very easy to game a system that is hourly-based and often results in schedules slipping, or worse: some team members doing heroic efforts near deadlines to make up for other team members that think they've done their work because their timesheet said so.