Having done some non-trivial things with threejs, I'd guess it's basically like this: 3JS is the rendering engine (taking advantage of WebGL); game logic is in Javascript; ktx2 is an OpenGL container holding the world data and other meshes; from looking at the filenames, WASM bits are used for loading the ktx2 data (draco_decoder.wasm). ogg files are for sound. The multiple worker files imply that the app is using web workers to run the WASM performantly to load the world.

ktx is Khronos Texture a format for storing compressed textures (=image data) so that they can be uploaded to GPU memory without decompressing step inbetween

drc is Draco Compression, it's a library from Google to compress mesh data

KTX can just store compressed GPU textures as-is, but in this case they're using the Basis Universal codec which is a bit more involved. Basis stores textures in a super-compressed form, which is decompressed at runtime to produce a less compressed (but still compressed!) format that the GPU can work with. The advantage is that it's smaller over the wire and one source file can decompress to several different GPU formats depending on what the users hardware supports.

ktx2 = textures

drc = 3d shapes (I think)

ogg = audio

All of these would normally be bundled in the game installer, but are sent down piece by piece over the network in this case.

Then there's some wasm and js for the game's business logic. The browser has WebGL APIs that enable running all of this.

I'm assuming they used a library or engine like Unity, Godot or Three.js that supports WebGL as an execution target.

The NPC at the top of the building sais it's three.js

Definitely Three.js or at least something similarly low-level. I doubt you can get this kind of performance with Godot or Unity on the web.

There is Needle.Tools for porting Unity projects to WebGL/3js

Threejs is like the jQuery for building 3d stuff. But it's not a platform like Unity or Unreal engine. But it doesn't look overly complicated.