The tileset has been provided internally, and it turns out that my guess was right in this case: The bounding volume of the tileset did not contain the actual geometry data from the GLB files.
The geometry data in the tiles has been “centered at the origin”, i.e. with a bounding box like (-1,-1,-1)-(1,1,1). But the tileset JSON defined a bounding region, which is always in latitude/longitude/height (EPSG:4979), and essentially describes bounds on the surface of the globe - therefore, it cannot contain the geometry data that is located at the origin.
The solution was to insert a proper transform matrix in the root tile of the tileset JSON. The transform that had to be inserted was the one that could be computed with Cesium.Transforms.eastNorthUpToFixedFrame from the bottom center point of the bounding region.
As described in the specification, this transform will affect the geometry, but it will not affect the bounding region - meaning that it will move the geometry that is contained in the tiles into the bounding region that is defined in the tileset JSON, so that the geometry is displayed at the right position in CesiumJS and other viewers.
As noted above: This is something that should be checked by the validator. And in fact, there already is an issue about that: Validate that geometry is fully contained in bounding volumes · Issue #233 · CesiumGS/3d-tiles-validator · GitHub . There are still aspects that make this a bit difficult. For example, for things like I3DM or GLB that contains EXT_mesh_gpu_instancing, or even just morphing or animations, it can be tricky to compute the actual bounds. And in any case, it could be really costly in terms of performance. But it could still be worthwhile to add a baseline implementation (for simple B3DM/PNTS/GLB) that could be disabled by default, and enabled with some --performBoundingVolumeValidation flag.