In some ways, it's easier to go fast when you don't have to argue over basic strategy or maintain duplicate code paths. Even if you lose some contributors in the process.

Yes, but in this case it isn't just "some" contributors. Google used to contribute more then double the commit and people on the project.

http://hypercritical.co/2013/04/12/code-hard-or-go-home

Google was a valuable contributor. But a lot of Google's commits were not necessarily that high value to non-Chrome ports of WebKit. They had forked code paths for a lot of things (so changes on their side of the #ifdef fork don't help anyone else), web platform features that were not necessarily of interest to others, and refactorings that did not turn out for the better. We have since ripped that stuff out. They did also contribute a lot of very valuable things, most notably security fixes and new web platform features that were useful. In fact, we sometimes still merge stuff from Blink (and they sometimes still merge from WebKit). But hacking on WebKit is a lot more fun now that we don't have to argue about how things affect V8, or the Chromium process model.

You are right for WebKit as a whole, but Google didn't contribute much to JavaScriptCore part of WebKit, using V8 instead. So I think it is indeed reasonable that this part of WebKit's development will speed up after breakup with Google.