performance-wise, I am usually getting between 50-80 fps with the default scenery on the same hardware, depending on eye-candy settings - this seems to be "locked" to ~60 now. Keep in mind that osgEarth support disables most existing eye-candy features in its current form though.
On the other hand, frame spacing is much lower and much more steady with osgEarth running for some obscure reason - I have never really used libsvn/TerraSync post 1.90 (I think I looked at it in the rsync days), so I cannot say anything about TerraSync performance in comparison, but it seems obvious that osgEarth's threaded libcurl integration is pretty solid because it's downloading all the data without any major hiccups, it's roughly at ~ 900MB now in "OsgEarthCache" and the framerate never went lower than 55 fps here.
CPU/GPU utilization seems higher and "better" in comparison, i.e. higher utilization and less lagging - obviously without any custom shaders/effects running, so it's still apples vs. oranges.
But I don't think it's fair to compare this 1:1 to our stock scenery, because the approaches are so different, and because each approach has different advantages and shortcomings (effects, shaders, buildings, cities, vegetation), which is why I previously said that I'd love to see some constructive discussion post 3.0, to see how existing features could be decoupled and generalized, to be usable in both modes. Overall, performance really is impressive for the amount of data that is getting rendered in "real time" (well, at runtime) - and it completely confirms that we should be moving more of the TG tool chain into FG, and use more and more procedurally-created scenery.
In general, given the plethora of OSGEarth related projects and efforts, the possibilities are sheer endless now because the hard integration work is mostly done, so it will be hard to match the amount of new eye-candy features brought by supporting osgEarth from now on. Editing *.earth XML file is obviously also more straightforward than dealing with TG.
Then again, the approach is different - there are huge advantages to precompiling scenery in a distributed fashion like TG does, i.e. having "offline scenery".
My guess is that it will take at least 2-3 full release cycles for this to really "compete" with our conventional scenery creation workflow, and then it's really only an option for people who have the bandwidth and horsepower (CPU, GPU and RAM). However, professional/power users will definitely be interested in this, even in its current form.
Ironically, we haven't had any major scenery rebuild in years - and suddenly we're getting new scenery and osgEarth support at the same time