[delta-v]

Due to the nature of the format, loading USDZ will always be slower than loading glTf. No matter how many smart engineers and money you throw on it, you can't optimize it faster. It's due to the nature of the data it stored inside. It takes more computation to translate USDZ than glTf to the format renderer/calculation uses.

The example you given is actually irrelevant for consumer use cases. For consumers, loading speed matters. They are interactive apps. They can't spend too much time loading. While for film studio, they are batch rendering scenes. Loading speed is a lot less important.

[usdfan]

Actually, very few workflows at film studios rely on batch renders these days. Far more important to artist productivity are interactive workflows - being able to work in context at scale in and between DCC's, and therefore load speed was actually a huge design consideration for usd, and integration of USD's gl imaging system, Hydra Stream, into workflows, has been a game changer for many interactive workflows. Check out the paragraph "Maximize artistic iteration by minimizing latency" on the USD website's front page... or better yet, actually try out USD (usdview) with a modern allocator like jemalloc (since both ingestion and imaging in usd extensively leverage multithreading).