GitFlow: merge to master first or after prod release?

The project I work in is very chaotic, decisions change in a matter of minutes, so my strategy is to procrastinate as much as possible software configuration management decisions.

Particularly, merging into master: we only merge to master after we deployed in production and we have a confirmation e-mail that smoke tests worked fine. This way we embrace chaos by managing the risk of decision changes, rollbacks in the deploy, technical problems or whichever issue may happen.

At the beginning we merged into master before going into production, but technical issues, rollbacks, management decisions at the very last minute... caused lots of problems to us, so we changed the strategy, and it's been working fine for the last 3 years.

If, eventually, after going to production some regression is found, that's a hotfix and must be handled like that :)

The release branch that you create is a short lived one, similar to the feature branches that you create. Once the release is finished, you delete the branch. For example, I would create a release/0.1.0 branch, do the work, and then merge.

When deploying to production, I always take the code from the master branch, meaning that I merge the release branch into master first, before deploying.

GitFlow is more about moving forward, not back. Hence why hotfixes are used to create fixes for issues that are identified.

In terms of time taken to get into Production, that is really not a concern of GitFlow, and i don't think it will provide much help in this area. This would be an issue for you regardless of which branching strategy you use.