People who say JS on the Quest 2 isn't fast enough to do good VR don't know what they are talking about. The problem is that a lot of small, indie developers only know the most naive way to implement things and then blame the platform for their lack of algorithms training.
I had originally started the project in Unity 3D. I eventually rewrote everything in WebXR because--while the naive path in Unity was faster than WebXR--the ideal path in Unity was nearly impossible to implement. I haven't done anything in Unity for about 3 years now, so maybe it has changed, but basic things like decoding textures happen on the render thread, which makes it impossible to use the Unity happy path to implement a dynamic XR app that wasn't prone to making people puke. While I was still tilting at the Unity windmill, I had a large amount of code that was just dedicated to decoding images before using them as textures, tasks Unity should have been able to handle itself, except for the fact that Unity is built by people who have never had to make a game or app themselves before.
There's a reason the loading screens on VR Chat are so long and boring--they can't slipstream live objects in because they haven't done the hard work of throwing away 90% of Unity's bullshit framework code. So they have to hide the dropped frames behind a scene fade-in/fade-out.
With WebXR, you get the full browser ecosystem to work with. Web Workers. Web Audio being off-render-thread by default. Fetch API. IndexedDB. It's somewhat popular to complain about Web APIs because some of them have some weird quirks and most of them don't agree on how to design an API, but you have no idea how much worse it can get. If you think browser app development is bad, trying making an app in Unity sometime.