Hi & welcome,
I don't think there is a short answer that is "correct", other than encouraging you to search the forum and look up all the pros & cons stated in related discussions.
Now, when it comes to scripting vs. C++ the one thing to keep in mind is that it is indeed much easier to write FAST code in C++, but it is also much harder to write correct, bug-free, code. In other words, C++ code comes with the obvious benefit of performance, but stability is another issue - because it requires enormous expertise to write proper C++ code, especially whenever you are not dealing with code written from scratch, but with a legacy codebase like FlightGear, that already has tons of code written in C++, that must remain functional - especially anything involving multiple threads (i.e. using multiple CPUs).
Scripting on the other hand, comes with a compromise: it is more difficult to write fast code, especially when compared to C++, but it is also much harder to screw up things, and you can write code without having to know how to rebuild fgfs - i.e. it is also an option available to aircraft developers who don't necessarily need to be coders.
When it comes to Nasal in particular, you really have to keep in mind that it takes two things to integrate a scripting language inside an existing application: 1) familiarity with the internals of the application in question (fgfs in this case), and 2) enormous familiarity with the scripting language, not just the scripting side of things, but also internals like the VM. And actually there is a 3rd one: you want to have someone involved in the project who can handle any issues that may occur.
At the time, Andy Ross came up with his own "toy" language from scratch, called it NASL (and subsequently Nasal), and he also was an experienced FlightGear contributor, so that all 3 requirements were satisifed, and that's how Nasal ended up in FlightGear (however, it wasn't the first scripting option either, Erik added JavaScript support once and PLIB PSL was also integrated once - it's just that at the time, Nasal was considered superior by those interested in scripting - mainly for the 3 reasons stated above).
As others said already, today, there are plenty of viable options when it comes to embedded scripting - back in the day (early 2000s), Python or Ruby were not exactly mainstream either, and not even today are they necessarily suited for being embedded into an application like fgfs.
Lua would have been, and probably still is today, a more likely candidate when it comes to embedding an existing language into an existing legacy code base.
Now, asking why Python/Ruby or Node.js/JavaScript were not used instead is akin to asking why you didn't win the lottery.
Then again, there are very real technical issues - even if someone were to volunteer and contribute a working Python/JavaScript integration, there is an existing legacy code base that comes with a certain architecture (read: cruft). Many (most) of the Nasal related issues are actually not due to Nasal but due to the fgfs side of things, i.e. the interface/method that is used to integrate the scripting world with the rest of the sim, and that would remain a challenge regardless of Nasal being used or not, FlightGear's architecture was never designed with such requirements in mind (referring especially to multi-core platforms and scripting outside the main loop).
If you are interested in learning more about the nitty gritty details, you could check the FlightGear wiki and look up articles mentioning "FGPythonSys".
Finally, even if you/someone were to provide a working Nasal alternative/replacement today, there is meanwhile quite a bit of existing Nasal code that the project has accumulated over the better part of almost two decades now. And from a coding standpoint it's not exactly straightforward to ensure that this keeps working, short of writing a Nasal parser and VM in whatever new scripting language is to be added (say the equivalent of nasal2python).
Other than that it's literally a mammoth task to provide a migration path for existing features implemented on top of/via Nasal.
And to be honest that is not specific to Nasal or scripting, it's a general thing when switching back-ends: There is an ongoing effort to replace the built-in FlightGear GUI (called PUI) with something Qt5/QQ2 based, and it's literally become a multi-year effort (all shouldered by a single enormously experienced fg core developer) without much/anything tangible (or even just visible) materializing in terms of Qt-based dialogs/UI functionality that is a concrete runtime replacement of PUI.
Nevertheless, nobody is arguing that PUI would be superior to Qt5 (far from it), but there is a certain degree of legacy functionality that must remain functional regardless of the technology stack/back-end in use , short of someone offering to rewrite such features using the new technology stack (scripting or UI).
In addition, the transition period can be rather long and painful, too - for instance, in the case of the UI transition, the community has been repeatedly asked to put other efforts on hold and not to work on alternate UI back-ends (e.g. via Canvas), in order not to derail the underlying core development effort, despite other attempts actually having produced workable in-sim replacements of some PUI widgets/dialogs, years ago already.
Thus, such back-end migration are likely to cause friction and irritation, especially if they prove unable to deliver on their promises (in retrospect). And that also applies to other efforts that were rather aggressively promoted by some senior folks, without delivering much over the course of a whole decade (e.g. HLA/RTI has been repeatedly referred to as having a reputation for being "pie in the sky" by other contributors).
Which is just one way to make the point, that sometimes people let the perfect be the enemy of the good (enough), spending years debating and re-implementing existing features without a proper reality check, i.e. a pain/gain analysis:
https://en.wikipedia.org/wiki/Perfect_i ... my_of_goodhttp://wiki.flightgear.org/PUIhttp://wiki.flightgear.org/Qt5_Launcherhttp://wiki.flightgear.org/QtQuick_use_in_FlightGearhttp://wiki.flightgear.org/Pui2canvasBesides, while re-implementing a working Nasal VM would of course be possible, that would not magically fix up coding issues that crept up in Nasal code due to mainloop/interfacing issues (think timers/listeners used to implement complex subsystems inside the main loop).
Thus, some fictional Python/JavaScript or Ruby module would have to deal with machine-translated Nasal code that is using the same problematic programming paradigms. And it's worth taking into account that not even all C++ code is using the recommended SGSubsystem/Mgr based APIs either.
Now, when it comes to truly Nasal specific issues (think the mark/sweep garbage collector) it would definitely be less work to fix up that (as in integrating/supporting alternate GC schemes) than integrating a new scripting language, let alone replacing Nasal in its entirety.
From a software engineering standpoint, Nasal is much better prepared for leveraging modern multicore hardware than the legacy FlightGear architecture is. It is very unfortunate that none of the SGSubsystem APIs were ever fully exposed to Nasal space so that aircraft/scenery and addon developers could use those instead of timers and listeners.
https://en.wikipedia.org/wiki/Scripting_languagehttp://wiki.flightgear.org/What_is_Nasalhttp://wiki.flightgear.org/Nasal_FAQhttp://wiki.flightgear.org/Nasal_success_storieshttp://wiki.flightgear.org/Modernizing_ ... _Scriptinghttp://wiki.flightgear.org/Python_in_FlightGearhttp://wiki.flightgear.org/FGPythonSysTo be honest, whatever you find in FlightGear in terms of concrete features isn't necessarily there because it's superior on technical grounds, but rather because FlightGear is evolving "organically", so that features getting implemented has more to do with who is/was around at any given time and what expertise they could bring to the table, and what FlightGear had to offer in terms of interfaces/extension mechanism.
For some features this has obviously worked out rather well (think property tree, XML), for many others it hasn't worked out at all in retrospect.
There's some shining examples actually - for instance, a scripted weather system (originally called local weather, now referred to as Advanced Weather) that was at some point entirely prototyped and implemented in scripting space using Nasal, despite some rather strong resistance among some of the most senior project contributors, who were hoping for such "key" (read: core) functionality to be implemented in C++.
However, due to the choice of fgdata-level extension mechanisms (base package), there was/is no endorsement needed by those overseeing the development of the simulator "kernel" (core developers) - this has obviously pros & cons, especially from a QA standpoint (not referring to the weather system).
There are other examples, like spacecraft implemented inside FlightGear without any support from C++ developers, so that new avenues can be explored without core development necessarily being a bottleneck.
Besides, it is worth keeping in mind that for many 3D modelers wanting to develop aircraft, FlightGear scripting via Nasal is often their very first exposure to scripting/coding, so that Nasal provides for a fairly low barrier to entry, while still using a syntax and programming paradigms that may come in useful at some later point in time, e.g. when writing shaders (Nasal's syntax is very close to C, which is what GLSL is also based on to some extent).
Finally, someone like Thorsten who literally spent a decade of contributing to the simulator primarily via Nasal coding, is unlikely to be particularly thrilled by announcements to phase out Nasal, or even "just" to see his contributions getting machine-translated into a language/style that he may no longer feel comfortable with (regardless of the programming background)