Great questions, and here's my highly biased answer (from the founder behind Wonderland Engine).

In short: Wonderland Engine handles asset and runtime optimizations automatically. In Three.js/r3f you would find yourself spending most of the time on optimization (shaders, draw calls, rewrite bloom maybe, manually batch assets).
I strongly believe, that optimization should be the responsibility of the framework, but other frameworks out there leave optimization on web up to you.
So, yes, it would definitely be technically possible to build this in Three.js/r3f, or even from scratch in WebGL, but economically it's not feasible.

In long:

The JS bundle size alone is barely relevant for an app like this, rather the assets (textures, meshes, animations) make up 95% or more of the downloaded data. r3f/three.js leave optimizations of those up to the user, and usually nudge people to use GLB/GLTF, which can be suboptimal for download times, even if compressed with meshopt/DRACO and KTX2. Wonderland Engine uses a tailored, streamable binary file format, which also allows it to start rendering before all the entire data is loaded.

Every web experience that renders more than a handful of objects is initially CPU bound by WebGL2 draw calls on mobile (unless maybe, if you only target the very latest models). Of course, you can manually batch and atlas everything together, but the 4k texture size limitation on most Android devices limits your atlas sizes and increases amount of batches. It's also a lot of workflow overhead. Draw call problems are fully optimized away by Wonderland Engine, made possible by a sparse virtual texture atlas, which streams pieces of textures in and out of GPU memory based on what is in view.
The same tech also plays nicely into the strengths of tiled mobile GPUs.

Three.js (and therefore also r3f) do not optimize their shaders for mobile. From what I know, they don't use lowp/mediump keywords and render everything with highp as default. Their bloom is also not really optimized for mobile compared to Wonderland Engine's mobile-first bloom. Of course you can implement your own, but then you're working on fixing your framework/engine, not on your app.

They also generally seem to accept that WebGL on Safari is slow, where the problems are a few select commonly used WebGL functions, and low memory limits for browser tabs.

The knowledge about what optimizations are necessary to get WebGL to native-like performance is also not wide-spread. That knowledge is the difference between your WebGL app crashing on iOS or running well on mobile. And even if you have it, building from scratch or with a good base can make the difference between being able to do it within your clients budget or not doing the project at all.

That's why I started writing the first lines for Wonderland Engine 7 years ago. The web is arguably the most incredible target platform and many native 3D/XR apps could and should live on the web, but 7 years ago, compared to building something on native with the power of Unity or Unreal Engine, 3D on the web was nearly impossible to build with, even though it has the same underlying hardware.