you need to make sure that you are not comparing apples and oranges here.
But regardless of the actual numbers, Python does support different GC implementations/schemes.
The on used by Nasal is a conventional "mark & sweep" collector implemented using traditional algorithms and data structures, it is a single file and just a handful of functions that would need to be updated to turn that into a generational (incremental) scheme where younger generations are collected more frequently than those who have already survived several GC passes. For details, please refer to the GC article on the wiki, and see Andy's quotes there.
However, a scripting interpreter embedded via HLA/RTI would not have any direct impact on frame rate/spacing, because it would be running in a separate thread/process, and only do certain IPC/RPC with the fgfs main loop (rendering).
Security is a valid concern, and one that has been raised by Melchior and others previously.
However, web sockets can also be accessed via Nasal.
Like Thorsten said, stuff like matrix operations could be also easily provided to Nasal - the thing to keep in mind here is that numpy is not just python code, but that it does use lower-level C/C++ (or even assembly code), e.g. highly-optimized stuff like libblas - which is to say that the raw power is not so much coming from Python but the fact that these are well-maintained bindings exposing existing libs to Python.
Obviously, it would be pointless to recreate such a module in C/C++ from scratch, but the same libs (BLAS & LAPACK) that numpy etc are using, could also be provided by a thin Nasal wrapper, e.g. using cppbind.
So by mentioning OpenCV, numpy etc you are really just proving the point that you don't want a different language, but that you want more/additional bindings for existing libraries.
That is a point well taken, but also one that must not be taken lightly, not just from a security standpoint (which is relatively safe to ignore given FG's primary use-case), but also from a deployment standpoint - i.e. python development being easily much more active than FG core development, and the plethora of 3rd party modules that people may want to use with FG, would cause addtional issues.
Nasal is relatively difficult to abuse, you need to have fairly good understanding of its internals in order to break FG and the way it is embedded in a sanbox'ed fashion - with Python, a sandbox environment could also be implemented, but as can be seen here, people will definitely want to use certain modules like numpy, opencv etc - and they want to be able to use tons of other libraries, sooner or later there will be a dependency hell resulting from it - imagine having to install different python/lib versions for a particular aircraft/feature (like bombable, advanced weather, fgcamera etc).
Python supported as a federate via HLA/RTI would not have much of an impact on frame rate/spacing at all, so the GC scheme used is kinda irrelevant - but that would also apply to Nasal once/if it is moved to a separate thread via HLA/RTI.
Again, integrating Python in a SGSubsystem fashion would not be much work, but it would be also subject to the same issues that Nasal is currently seeing/causing (including the GC issue).
Thus, it would make more sense to pursue Stuart's and James' approach and move Nasal to a HLA federate, possibly in conjunction with an improved/generational GC scheme (gc.c is tiny and straightforward code).
From a computational standpoint, numpy, cython etc may be great - but for FG it would make more sense to use OpenCL for such features - which is admittedly also supported by Python via pyopencl, while many of such libs come for free, there still is a certain cost to actually use them, and if that comes not in terms of runtime footprint, it will be an increased management/security footprint.
In general, it would make sense to formalize the whole decision-making process when it comes to introducing/accepting new/optional dependencies, because that is indeed a fairly common irritation/theme, e.g. look at the OSG port, boost, Qt5,C++11 or now Python.
It would be great if this could be raised during one of the upcoming "hangouts" so that a corresponding "policy" document could be drafted, supported/endorsed by all active core developers, and published on the website/wiki.
I am not opposed to Python "per se", I am just opposed to not thinking it through - apart from that, I think that OSG/Python/Qt5 etc could be great technology enablers in the time to come.
The C++ integration code exists already, in the form of working Nasal bindings, which are straightforward to adapt for Python use - so that is a no-brainer in comparison to the can of worms this is opening in the years to come, if not done properly.