Having worked at a company that did a four-day week, I'll chime in that it was both amazing and eye opening. I say that as someone who had read Tom DeMarco's now-classic book Slack[1] long ago, after a lot of up-close and personal with the antipatterns described therein. Intellectually, I expected something(??) good but the reality was even more suprising. With a four-day work week, I was able to complete (solo!) a production website application upgrade (Rails 2.x to 4.5) in a very reasonable timeline, and less than I'd heard competent teams failing the same task elsewhere. This wasn't because of any "10x developer" nonsense - it was clearly because I had a /three-day weekend/ every week and came in on Monday clear headed and ready to HIT IT, BABY.

Let me be clear: I later realized that this project would have been a soul-draining death march at many other places I'd worked in my career. Exhausted just a few weeks in, with management hounding the team for schedule estimates that can't possibly exist because management failed to fund maintenance for years.[2] (There were actually rational reasons for this, in this case. tl;dr the project got renewed interest and investment due to a new business case.)

To those who lament on this topic about "devs (in country X) just aren't motivated these days" or whatever, let me suggest something. If you have poor clarity of purpose, poor giving-a-fsck about humans, or a number of other culture failings then yes, you may encounter problems. Your solution is still not to tie your knowledge workers to their desks. You need to fix the root causes of your underlying productivity debt, not pave over them with an overwork-butts-in-seats mentality which just makes things worse in the long run (<--- read DeMarco).

[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

[2]: Pro tip: "evergreen" ecosystems, especially young and rapidly changing ones like early-mid Ruby/Rails and a lot of current npm/JS-based stuff, often have a wickedly non-linear cost curve if/when maintenance and dependency updates fall off. Some of the most expensive I've encountered of this ilk is when /test infrastructure/ incurred a lot of past churn that wasn't tracked, but suddenly (cough) needs to be updated.