Hi hardcoremore, nice to meet you. I've been struggling with Scout and performance optimizations myself and have been reading and sympathizing with your discoveries. I took a look at your logs, and while my experience has been very different (your telemetry looks amazing btw) I wanted to share some of my observations and hopefully make a connection with a fellow Starling developer.
So, for starters, I too am seeing a large amount of performance going to Context3D.clear. But, what's utterly frustrating about it is I can't seem to figure out how to optimize this due to a mysterious behavior I'm dubbing the "throttle factor".
It seems that on mobile devices, any attempts I make to eliminate performance bottlenecks I'm observing in Scout simply results in the remaining processes stretching to fill the space (rather than leave me with unused frame budget, which is want I want to see).
Here's some specific examples:
1) Because I use pure asset SWFs and rasterize my vectors into textures dynamically, I was seeing 35% or more of my frame budget being spent on "Running SWF tags for frame". I identified the problem, found a fix for it, BUT, after making the fix, the remaining frame events simply *increased* their processing time, leaving me with 0 net performance gain. Read more here: https://forum.starling-framework.org/topic/running-swf-tags-for-frame-scout
2) I've observed behaviors such as touching and moving my finger on screen or triggering the task notification bar on mobile results in a significant performance gain (5-15+ FPS) and eliminates the staggered "spike" pattern I would see in Scout with a more consistent flatline heartbeat. The only other information I can find on this was here: https://forum.starling-framework.org/topic/rendering-is-significantly-faster-when-touching-the-screen
3) I turned off my CPU heavy operations (ex: my armature processor) and even turned off my world clock to stop animations. You would think this should result in super smooth performance? No! Instead, the baseline Starling rendering simply expanded its operation times, resulting in higher MS/per method usage than before.
Most of my test were done using an older Android Nexus 6, but I've observed similar behaviors on my other Android and iOS devices. I believe there is something specific with mobile devices and/or the AIR runtime that is requesting a certain "resource" amount based on a performance threshold. As demand for resources increases, so does the CPU/GPU power thrown at the app (hence the "throttle factor" name). However, in my case, and maybe yours as well, once you reach a certain optimization level (for instance, I've got everything running on 1 draw call) then the app has potential to "misjudge" the necessary resource, and throttle down the resources given to your app, resulting in choppy performance when it should be butter smooth.
This is just a theory, and I would love to hear back from you and other developers if you are observing similar behavior and have found a workaround. I suspect this may be affecting you, given what looks to be a highly optimized app from your telemetry data.