The Living Downstream Without Drowning talk from the 2015 US Dev Meeting might be helpful.
At Sony, we used to merge from upstream once every 6 months; this would cost roughly 3 person-months of effort, due to the extent of our changes (and for many of those merges, I was the person). We evolved to a continuous-integration model, allowing us to apply automation to the problem; last time I added up the numbers, we were averaging roughly one merge conflict or test issue per day, most of which are very low effort to resolve.
Living at the tip of ‘main’ has advantages, the main ones being (a) you get the latest-and-greatest to work with, (b) if your downstream testing finds issues, it’s much easier to get them resolved right away than it would be six months later. The main disadvantage, of course, is (c) you get the latest-and-greatest bugs too.
We merge from upstream, rather than rebase. This was, initially, because we didn’t know any better; however, once we had users outside the immediate team and multiple releases to maintain, it made sense to merge rather than rebase because having the combined history on our master branch was consistent with the combined history in our releases. Bisecting to find the origin of a problem makes it pretty straightforward to determine which releases are potentially affected (or not).
It does make upstreaming patches more, shall we say, interesting. As it happens, just last week I did a complete diff of our tree with upstream, and we have a couple dozen patches that could be upstreamed; anywhere from typos to significant features. Because we have merged rather than rebased, the need to untangle patch history increases the effort of upstreaming, and so we don’t do it as much as we really ought to. However, reducing the “surface area” of downstream patches means lower chance of merge conflicts, which simplifies merges and makes them less costly; I recommend it highly. The talk mentioned above has a couple other tips and tricks to try in this area.
So, if you have existing releases/users to support, I think the case is stronger for merging; otherwise, the conventional wisdom is to prefer rebasing. Certainly rebasing makes it simpler to upstream a patch, and I think also can make it easier to track down bugs in your own patches versus upstream behavior (something that we often struggle with).
Good luck with your efforts!