Not true. We've also found that rebasing our own work onto the latest master makes it a lot easier to deal with conflicts. When you do a merge, the conflicts you see are a mixture of your own code and someone else's code, and it can be hard to tell which is correct because you're not familiar with the other person's changes. But when you rebases, all of the changes are code that you wrote, so it's easier to figure out how to fix the conflict.
This may sound counter-intuitive, because you're thinking it's the same conflict either way. Most of the time it is; if you and someone else changed the same bit of code, the conflict will be shown to you the same way whether you merge or rebase. Those are easy to fix. What's harder is when someone reorganizes some code without making significant changes to it. In a merge, you'll see changes all over the place, but in a rebase git can usually figure out the new line numbers, and may not indicate a conflict at all. The other area where my team has had difficulty with merges is in Visual Studio sln and csproj files. When you add new projects to a solution or new references to a project, git can present a very confusing diff during a merge conflict. But for rebase only your additions are highlighted, and most of the time you can solve the conflict with "use theirs before mine".