It's not churn for churn's sake. But having a policy of having drivers in-tree and explicitly not caring about out-of-tree stuff allows them a relatively free hand to improve the internals. Which is then seen as churn by out-of-tree code.

Meaning, internal things in chromium change so fast, so you'd slightly wish you could have your custom changes merged into upstream? (I.e into chromium)

So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors?

But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes are off topic to Google)

I wonder how much time does it take to merge a new chromium version into your repo? Like, hours? Days? Weeks

Yes.

Also, the fact that Chromium is a high profile security critical software with occasional emergency security updates for bugs exploited in the wild, doesn't help at all when you want to maintain your own fork.

Personally I see this as a good counterargument for "just fork it." Imagine if chrome decided to crank up churn with the intention to exhaust forks. Maybe all forks would join together to fight google or more likely they would just fall behind.

This has practically already happened; there are very few Chrome-based applications that actually stay up-to-date, and Electron isn't much better.