Yeah, I think you convinced me into not changing to native activity. I don't see a single advantage to it, from my current work state. For a newcomer to android development, perhaps, but I am too far into this race already to feel the need to touch this part of the program anymore.
I wrote a "standard" Java activity using GLSurfaceView and then replaced some parts of the Java Code with preprocessor tokens, for customizability. Then, I run my own sort of preprocessor on this Java source and template APK, and generate on the fly a fully ready APK for the new project.. The Java part already gives me access to sensors, vibration, assets and all, then callbacks the c++ for events / rendering and updates, which is really all the c++ part needs to run well.
With this approach, I was able to integrate ad networks like AirPush in no time before. That said, I don't need to touch java in ages, and when I need, the work needed to be done is really not hard because its just a standard use of the standard API, like integration of Facebook or Ads.
In this situation, I don't think I would benefit at all from a native_activity. Not for performance and not even for usability. One downside I find myself having was to be able to call opengl commands only from the rendering thread, which blew my plans to load textures in a parallel thread for the loading screen.. I thought native_activity and custom egl context initiialization could go around this issue, but as far as my research went, and from friend's opinions, it can't be done in android..
So yeah, I think I will indeed publish my games as they are now.
Keep up the good work with the tutorials ^^