I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it.

However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.

I'm not so convinced about the tradeoff.

With your own patches you know exactly the reason and intent for each one - you wrote it! So you can rapidly figure out what to change to make them fit with the new release.

But in reverse you are going to have to grok every new change sent your way, and that it going to be a massive amount of work.

Some of it will be easy stuff: It's clear what they are doing, or it patches cleanly and you don't worry about it.

But then you'll run into more confusing changes and you're going to have a harder time. There is a human tendency to ignore that which you can not understand, and you'll have some of those, then a patch on top of them, and the final result is more work than you started with.

There is no singular "you". Google is a 50,000 person company. The 70 patches were likely written by dozens of different employees for different projects with different code bases. Some of authors may no longer even work at Google.

The trade off is that your patches are for things that you clearly care about, and do not want to lose. Having played this game several times, several ways, whichever branch the "patches" come from is lossy.

Fewer surprises. You don't wake up one day and discover that TLS heartbeats have appeared in your library as a result of previous upgrades. Every upstream change has to be reviewed because that's the only way it gets in. Also, local changes are much less likely to be lost as a result of merge conflicts.

The downside is that you may miss some upstream changes that you do care about.