Feature branches were rebased then merged with a --no-ff. This creates a merge commit on master which includes the ticket number and short description.
The rebase is done by the feature branch developer who is usually best qualified to do so.
The advantage is that changes are isolated from each other, so nothing is spread before it's reviewed. The rebase makes the history easy to follow because it becomes linear and you can always easily see exactly what was changed in the branch. You still retain the full history of the feature branches.
Disadvantages: it doesn't scale to a massive team because you need to linearize the merges back to master. So it works for upto around 20 people.
I'd recommend against Git Flow because their method of merging makes it very unclear exactly what was changed in a branch. I actually prefer no feature branches to using Git Flow.
As the above post mentions I like to use feature flags to make this possible.
My team's process is simple and easy for anyone to follow: all feature work is done on feature branches. Branches should be kept small and atomic. When they've passed code review, squash and merge into Master.
If you need to pull changes from master, always merge into your feature branch, never rebase.
Rebasing is wonderful, it makes Git a joy to use. But you have to understand the process and, most importantly, train your team so that they also understand it.
As I've said, I've had great experiences working like this; but it took a lot of effort and support of my senior developers to get the team up to speed.
Of course, this does require someone to be more proficient with Git beyond the simple add, commit, fetch, push model, which has its own drawbacks.
Also, at least in Git, squash is just one use case of interactive rebase, so I'm not quite sure what you're arguing against...
git checkout master
git merge --squash some-feature-branch