In our experience RN loses, for our kind of applications (so I am not saying this is universally true!), from all 3 the above mentioned technologies in cost, time to implement and long term stability. We have apps running for many years while requiring fixes/feature additions in the meanwhile and that cannot cost a lot as they are small features/fixes. Requiring to refactor/fix things after updates of the platform is just not an option as we do not have many resources. We had incredibly bad experiences (in backend tech, so apples/pears but still) in that regard with Ruby/Rails and js/npm; that is great for big dedicated teams with continues development. We had great experience with ASP.NET (old+new) and Django; stuff just works after years and not much knowledge is needed to go from one major version to another (it did not take us much work to go from asp.net to asp.net core for instance).
Flutter definitely seems promising ; the foreign function interfacing is much better than RN (imho) and it just seems less like a mess. We will keep evaluating Flutter while working on/with Xamarin Forms (apps), Avalonia (desktop) and Livecode (everything).
This is for LoB applications like you seem to target as well; for consumer facing apps, we write native on all platforms, but that really does not happen often in my line of work.
The amount of work was non-trivial, however, in absolute time it was a few weeks of work that we have only done once after first creating the app many years ago.
It's likely that we we would have considered doing something like this even if the app was in pure iOS - Discord has gotten much bigger.
Mobile teams I have seen for apps at scales similar to Discord tend to run anywhere from 10-20+ dedicated engineers. By comparison I believe we have been able to accomplish a lot with a much smaller team.
Ha, you know React runs in web browsers, right? React developers should already be used to having their code run in various JS engines (Gecko/Blink/Webkit and SpiderMonkey/V8/Nitro).
My company has both natively developed Android and iOS apps, as well as a few RN apps. I'm in the developer tooling part of the company. Indeed, the RN apps did allow those teams to add developers who had only JavaScript coding experience. But at the cost of a lot of additional complexity elsewhere in the company. Now we effectively have to support three platforms in our build system, in our SDKs, and so forth.
I'm fairly confident that it is not a net win. Those RN developers eventually have to learn the weird idiosyncrasies of both Android and iOS besides the idiosyncrasies added by RN itself. They now have bugs that show up on only one platform because RN Android is using a different JS engine than RN iOS.
There's just a gigantic amount of complexity added by RN on-top of the gigantic amount of complexity you already get with Android and iOS.
In the end, at best you end up with a mediocre cross-platform app. I think RN probably has a sweet spot: a small to medium sized app developed by a sole or maybe a few developers. Once you're big enough to have teams of developers, I think RN is a mistake.
With respect to this article, the amount of work and expertise in both RN and iOS necessary to achieve their performance goals seems pretty extreme ("mobile performance squad"). And this was all just for iOS? Did any of it translate to their RN Android app? It's a counter factual so who knows, but I suspect the performance problems wouldn't have occurred on a native app in the first place, and if they had, would've been straightforward to track down in Instruments. They claim all this work is offset by allowing their web app developers to contribute to the RN app and that it allowed them to develop the iOS app more quickly, but I have my doubts. As it is, they've got three developers dedicated to the RN iOS app alone and despite that, still ran into performance problems.
Again, maybe they have enough shared code and developers to make it worthwhile, but I dunno.