Currently I am on a project and the developers can't come to an agreement of whether to use Rebase or Merge. Are you able to mix the to Gitflow/Workflow without it being problematic? Is so, why is that the case?
I understand that it can be problematic when collaborating and working on a Feature Branch. But this question is geared towards the Master Branch.
If you're using Git Flow, then you will definitely need to perform at least some merges, because the workflow involves merging different long-running branches. Trying to rebase one long-running branch on top of another is a recipe for difficulty and sadness; this is also true for performing squash merges. The only reasonable way to incorporate two long-running branches is a merge commit.
If you're using a more traditional workflow, such as the one used by Git or commonly used on GitHub, where you're incorporating code into a single main branch, then it matters less. It is better to choose one consistent strategy and stick with it, but you don't strictly have to. It is possible to both merge and rebase into the same main branch. Doing whichever one you please doesn't provide the linear history that rebase proponents want or the insight into fork points that merge proponents want, so doing that may result in everyone being unhappy. While that can be a valid approach in certain cases, it may result in undesirable conflict on your team.
I will say that when I need to make a technical decision related to version control and it involves a tiebreaker decision, I do what Git does. Git is reasonably successful as a project, and it uses a merge-based workflow of feature branches. You may choose other tiebreaker strategies, such as what your preferred language runtime does.