Are there any advantages of raising a pull request and then merging instead of pulling a branch to local and merging to the target branch? This pertains to a small working team.
Although the end result would be the same, I do think that there are a few differences between using PR + merging instead of pulling and then merging locally before pushing to remote.
From a development perspective, we are creating a PR because we want other people to view our code, test it, find bugs with it, style it, and comment on everything that is not right with it. That way we make sure that the code we are writing is correct and will not cause 3 AM calls from the boss. Git by itself does not have the concept of a PR, so we use things like GitHub/GitLab/Bitbucket to manage PRs and to make code reviewing easier. By easier, I mean all people are looking at the same code at the same time and all of the comments on a specific PR can be viewed and discussed.
Now apart from that, there are some minor differences between the different systems we use to view PRs. I don't know what you guys are using, but almost all of the different hosting platforms allow you to quickly manipulate the PR:
On its own, these seems like small things, but if you have to manually merge a branch, then delete the source branch, then push it to the remote, or if you have to manually rebase and then merge it... that's a hassle. It's faster to just click one or two buttons and be done with it than to handle all of these things on your own (and again, this depends on the system you are using).
I believe that even for a small team, having a system for PRs would be beneficial, but you have to decide that for yourself and what would work best only for your guys.