I do octopus merges very rarely, so there's no single common scenario where I default to them. It's just that Git handles them so poorly that in the rare cases where I do one the problems stick out more.

Off the top of my head:

- I was working in a large organization, and building a prototype of a feature that another team wanted to start consuming on their dev branch before it was merged into stable. We could have rebased all of their changes onto a new branch off of mine, but I thought, "meh, why not try to give their branch two parents just to see what happens." Long story short, I will not do something like that again.

- I sometimes work on Open Source code with protected branches. Once the code is merged into stable, it's all MIT licensed. Before it's merged into stable, it's not. One time I had the deceptively bright idea, "hey, why can't stable merge from two branches; one that contains license information and one that contains code?"

It's all fairly rare edge case stuff that's avoidable with a little bit of discipline and practice, but especially if I'm working with a large number of feature teams, I will sometimes notice that I'm relying on cherry-picking and rebasing not because it makes more sense than an octopus merge, but because it's just generally less dangerous to do.

Cherry-picking has its own set of problems, because when Git does conflict resolution, it cares about commit order. This means that cherry-picked commits can sometimes overwrite later changes from the source branch after they've been merged.

These are problems that I don't know how to solve, so I just avoid them. But if a VCS did solve them, I would be tempted to switch.