I'm not a fan of rebasing as it makes for a confusing git history when you are working with Gitflow. I find it much nicer to see the merge bubbles which indicate how features were introduced into a release. Flattening the history makes it tricky to get a clean overview and pick precisely when certain actions were performed.
i.e. before merging a feature branch, always rebase it on the tip of the integration branch, then merge it in with --no-ff to record an explicit merge commit on the integration branch, even though a fast-forward is possible. This gets you the temporal straightforwardness of rebase while preserving the fact that there WERE feature branches and their commits are partitioned in history.
Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this branch or remove the entire feature.
In this debate I am a strong rebase advocate (though more than that I'm for very carefuly and actively avoiding there being remote head contention - for instance by having feature branches with clear owners, or having a PR and code-review based integration style), but when merging features in these should definitely be (--no-ff) merges.
It's not a dichotomy, it's about clear semantics - what a feature branch is (clearly defined linear progress off of an upstream) what a merge means (integrating that progress and vetting the result).
I feel like this echoes the tables vs divs debate: use a table for tabular data and position containers for layout.
In both cases, there are some fringes who argue that you should do one or the other for both use cases - semantics be damned. Git is newer so the fringes are just bigger.
-imo