I've been working on a faster Second Life / Open Simulator client. Those have a reputation for being sluggish. That's rapidly changing.
All content is loaded on demand. Textures are stored in JPEG 2000 format. JPEG 2000 decoders come in several flavors - slow and flaky, fast but need the GPU, and midrange but expensive. If you want to rewrite OpenJPEG in Rust, go for it. You can download part of a JPEG 2000 file and get a lower resolution texture, and that's what's done for distant objects. The general idea is to download textures at a size that gets one texel per screen pixel. (Yes, subpixel textures would be better.) Textures are locally cached to SSD. Background threads are frantically loading and unloading textures in the GPU at different resolutions as the viewpoint moves. The highest resolution is compressed losslessly; the others are lossy.
In metaverse systems with user generated content, there's not much instancing. So the texture load is much higher. Wander around Cyberpunk 2077 and you'll see the same railing show up in completely different contexts. This doesn't happen in worlds with user-created content. There's no producer or art director to insist on reusing content.
If your game downloads content on the fly, you need substantial content delivery capacity. Second Life front-ends Amazon AWS with Akamai. Open Simulator, on the other hand, often just hosts the content on a single game server, along with the the simulator itself. My own viewer pulls about 200Mb/s from the content servers for about 15 seconds when you first connect. Then it's done until the viewpoint moves.