The idea that resolving conflicts in a merge commit is better than in individual rebased commits is very very wrong. It might be more expedient, but it is also more likely to do introduce a difficult-to-bisect error than considering each commit as if written in the current state of the world.
Like everything that's nice in theory, in practice rebasing is the only way to keep your sanity. It may be used in a quilt-like manner to apply your own changes to a foreign code base. For example, this is useful to develop features before they are ready for upstreaming. With rebase, you are applying your own changes on top of changed code, not the other way around, a much simpler and better scoped (in terms of time) activity, especially when the underlying codebase undergoes radical changes of its own. And whrn you're done and ready for upstreaming - you have a current set of simple changes against upstream, that are easy to review one by one, not a weird mixture of bits due to merges.