I'm not part of the LessWrong developer team, but I am a software developer. Generally, a relatively complex app like this would at least require an developer or two working full time for a year, which would be a very significant up front investment, plus any new features would have to be developed for both platforms in the future. This is doubly true if you want both an iPhone and Android app and don't want to use one of the somewhat questionable cross-platform frameworks.
Given that the LW team is (presumably) budget constrained, this would mean that they wouldn't be able to work on anything new for the website during this time. In addition, the work would be completely different from designing the website, meaning that it might take extra time because the team would need to learn the relevant skills.
On top of all of those supply-side constraints, there's also the question of demand. I'm sure that the app would be useful for you and for others, but I simply doubt that there would be that many users. However, I do think that it would be a decent idea to poll active LWers and ask them about various potential future features, including an app, and if an app got significant support, then it might be worth prioritizing.
Given that native mobile apps are often written in C, objective-C or C++, just on a simple language level you should expect something like 3-10x speedup from the switch from an interpreted language to a compiled language (sometimes more, sometimes less, depending on the application). In general interpreted languages continue to be substantially slower (and though interpreted languages have been getting faster due to smarter execution environments and lots of fancy tricks, so have compiled languages, due to improvements in compilers).
The comparison is pretty similar to the python vs. C comparison, which I have a good amount of concrete experience with, since it's super common that if you write ML code, and want to optimize any specific part of it, you rewrite it in C or C++ and then call that C code from Python. Doing so usually gives you something like a 10x performance improvement, though it depends a bit on exactly what you are doing. I expect the difference between C++ and javascript to be similar.
So yes, I do think that progressive web-apps running on javascript does mean they are fundamentally slower than native apps written in C, C++, or even Swift or Java. This doesn't mean it's impossible to write a performant progressive web-app, but it does likely mean that you have to put a lot more thought into optimization than you would if you were to write native code (also because the javascript ecosystem really isn't well-optimized for performance, and so it's really easy to build a non-performant app).