Merge is a simple way to manage your code, with a very clear git log/history that tells you when changes from different branches were combined. Your changes are clearly differentiated from merge commits, which will even be helpfully greyed-out in most popular hosted git services. They can get pretty unwieldy if you let a branch live for a really long time, particularly if you aren't updating it regularly. So try to do short, contained branches and update them regularly. Keep a clean workflow - never work on master, always branch from master, use pull requests to merge back to master.
Rebase and its constant companion squash are for the thrill-seeking developer, who prefers a little uncertainty in their life. When were the changes merged? Who knows! The history will tell you the PR your coworker just raised was completed three days ago. Everyone loves a bit of mystery in their history! Maybe rebase will fail and require you to do a tricky set of actions to combine upstream changes, because a simple conflict resolution just isn't a hard enough problem - we like proving we're really smart by solving hard problems right? One wrong move and you've just reverted that critical fix your team mates worked so hard on. Go team! If you're really lucky, rebase will totally explode and you'll spend hours with a lovely puzzle to figure out - much better than getting that critical bugfix released. But in the end, rebase will avoid a few greyed-out commits... and all that effort will seem totally worthwhile.
Jokes aside a rebase workflow does work fine, I just prefer merge ;)