I absolutely buy the part of Joe Kraus' Hackathon post that says that short focused bursts with a focus on actually shipping is how the really good stuff gets done. The problem with hackathons is that they are not, in my experience, truly sustainable, reproducible events.
My personal experience with Hackathons come from doing maybe 10 of them, either alone or with 1-2 co workers. This has been possible where I've worked due to trusting or hands off management - either way works if you have geeks of quality on your staff.
Management of that kind is a prerequisite, but it is not how hackathons get done: You need an itch to scratch. Good ways to find itches are "stuff is cool", "stuff is really, really late and really, really necessary" or just that you genuinely have an itch to scratch.
The problem with hackathons is that if you try to run a hackathon as a "process" without that itch, you'll get nowhere fast. A day off the map with less than 100% motivation is just a day off the map. I have tried, and I have seen colleagues try, to falter because the itch we felt wasn't genuine, which meant that the hackathon wasn't the focused energy boost it's supposed to be, but just a day with an undefined task and a tight deadline.
But when it's good it's good. I think all the really essential core ideas in our product has come out of sessions like hackatons.