I've been reading a bunch of articles on how to organize your git repository and the most popular method seems to be GitFlow.

However I've also read articles about the downsides to it. Most of them all seem to say it gets a bit messy to follow as reading the entire history is split into a bunch of branches. Gitflow people argue "well that can easily be handled by a good client". I see both sides to it as well as the other argument that, especially for smaller teams, it can get confusing what branch you should commit to or currently be using...

I feel like GitFlow would work the best for the most part, but condensed. So for instance instead of having hot-fixes always on a separate branch, only branch them when they are really complex and multiple solutions may be need, but for most hot-fixes, just use the master. Same goes for releases, simply use the master. You already have tags to know about stable releases and those are much easier to move around and change if say it wasn't quite ready for release and you still need to tweak some stuff. Plus then the master isn't just merges.

This leaves you with just Master (stable releases are tagged, most hot-fixes and release candidates), Dev used for most of the development except major new features that need their own branch and are then merged in, Finally unique feature branches for each major feature that is being worked on.

Does anyone see an issue with this? Is there a real reason to have separate release branches? Or even one that is used for every pre-release/release candidate?

Only thing with hotfixes being on another branch is I guess you can merge them into dev as well as master.