Well, what would be the argument against that - if in fact it does deliver code that solves a problem in a short period of time? Why can't you just do that all the time?
Having a fairly small, well defined problem, working in a small self-selected team, with no outside interference and typically no clients outside the team. No managers, no PMs, no bug reports. This is not how day-to-day projects get done.
Regardless of all of that, in my experience a typical impressive hackathon project is still just a barely working demo that benefitted from a significant amount of research and planning beforehand, and will require an even greater amount of hardening and polish afterwards.
There is no magic, it's just a vastly different kind of work environment with both inputs and outputs incomparable to day-to-day work.
The place where I'm working has done a corporate "hackathon". It took place on a normal day and I don't think there was any overtime, we got free food, but all projects that delivered something relied on existing research and need a good deal of polish afterward.
Same reason you can't drug up or taze the special goose to produce more golden eggs.
Long term high intensity output will lead to burnout, even if the salary is 10x people would struggle and crash. Pushing at 100% full enthusiasm is like sprinting, it is not possible to maintain that intensity for very long. It can be fun, it can be productive, but the wiser approach has the long-term and end in mind.
Sounds like a good argument for always introducing an artificial fatal flaw into your project before presenting it... so proj management can’t see it and yell “my god, it works! Let’s put this cobbled together, coffee-fuelled mess right onto prod!”
