Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every day. I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.
8+ hours is not okay not every other day or even less frequently. Ok, once in a while is ok if one is in a good rhythm and they are enjoying themselves. But after 4-6 hours productivity drops sharply and starts to erode from the following days: fixing up poorly made design choices, etc If your employer expects you to be productive 8 hours a day I’d look for something else
There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better.
There's also the bullshit long-hours work culture where leaving work before the boss does is somehow unacceptable.
The best approach I've found is to explain that the codebase is an asset that can be damaged. And the code itself is a liability - it must be maintained in the face of changing requirements and technology. "More code" is worse, not better, for the company. So having tired developers write bad code is both damaging our asset and introducing more liabilities. We need our devs rested and on their game to avoid that. We need them thinking deeply about the code they're going to write. And that thought doesn't have to occur at the keyboard. Good devs think about their code while going about the rest of their lives.
It's better if a tired dev goes home to rest rather than continuing working on the code, because they'll just end up damaging it if they work on it tired.
It's better for a dev to go for a walk to think deeply about what they're doing rather than write code that they're not sure about.
We don't want devs working on the codebase after ~8 hours, because they probably haven't thought enough about what they're writing.
It can work. Depends on company culture.
There's also so much bullshit in dev culture itself about "marathon hacking sprints". I bought into this myself, did a 32-hour sprint to meet a deadline. It was a complete mess. I would have been so much better off getting some sleep, a decent meal, and going for a walk in the middle. I think most devs go through this lesson at some point.