Experiments have repeatedly shown a solid increase in day-total productivity when going from 10 hour workdays to 8 hour workdays; similarly, there is an increase in total weekly productivity when comparing 6 days a week to 5 day workweek.
I doubt that the people who work[ed] on saturdays had a much different daily routine than those who didn't; but still, working that extra day only results in less work done.
You work that extra hour/day, week after week, and you see real productivity gains (not necessarily per-hour productivity gains, but marginally speaking, you make progress faster). As others have mentioned before, this trick can work very well in the short term.
However three months into it (roughly +150 man-hrs), you make a small blunder that nobody notices at first. One year later, it will blow up and set your whole team back for a whole month (assuming team_size = 5, -800 man-hrs). Everybody will try to catch up by staying an hour later, or working on the weekends... rinse and repeat.
The problem is that cause and effect are so far apart in time that nobody notices why this is happening. Usual suspects such as "rusty codebase" or "technical debt" get assigned with the blame and no lesson is learned.
As far as I understand, the experiments show explicitly less work done, as in, if you do the 60 hour workweek for prolonged time, then you have less widgets produced per week, period.
It's NOT a tradeoff of more volume for less quality and increased risk. All the drawbacks you list are valid, and come on top of less total productivity.
You don't get a product built faster but with more defects and technical debt. You get the product built slower; with more defects and techical debt; and at a cost to the workers personal life in a true lose-lose tradeoff.
I doubt that the people who work[ed] on saturdays had a much different daily routine than those who didn't; but still, working that extra day only results in less work done.