I don't think hackathons are always a gimmick, but then again I was probably too loose with my word choice. I mostly meant a period of sustained cooperation with a small group where most of the time is spent together, all meetings are canceled, and you don't try to split up work into bite sized pieces with any formality (like a story/jira ticket).
I agree that organizations that don't trust their engineers with any design or implementation decisions are wasting their talent and probably creating a lot of bored and burned out engineers. If an engineer wants to use a fancy new piece of tech and they can justify it, let them do it.
If I'm responsible for project A, I should be able to make 85% of the decisions for that project. Too often, recently, development organizations make every decision from above, then break that up into miniscule tasks that require no thought from developers.
Hackathons, IMO, are just gimmicks to gloss over a deficient product management group or software architecture. If your organization can't be convinced of the need to spend time on something outside of a gimmicky "hackathon", then something needs fixed.