I've never understood the complaints about rebasing. Just make sure you merge if it is complicated
Jokes aside: It honestly isn't THAT much worse. But if you don't "understand" git, you can fuck up your history and it is a real mess to recover from a "failed but technically not" rebase. Whereas merges just result in a shitfest of a history but everything gets reconciled.
Although, a bit of a rant: I do still think rebasing is fundamentally "bad" for long term debugging. As a simple example, let's say that you changed a function signature on branch A and merged it in. Branch B uses that function and started before A. After a rebase, there is no indication that those previous commits would not have worked or were counting on a different signature.
Generally speaking, you can avoid this so long as you always add a merge commit to go with the pull requests (or futz around a bit to identify the known good commits). You assume that those are the only valid commits and move from there. But when you are debugging a bug that silently got added two years ago and think you are clever because you know how git bisect works? You suddenly have a lot of commits that used to work but don't anymore.
It doesn't come up often (especially since so many workflows these days are "throw out the old code and redo it, but right this time") but you only need to run into that mess once or twice to no longer care about how clean your history is.