This issue is by design. The attached scene uses a custom skybox shader which reads from unity_SpecCube0, which is in an unspecified state when the skybox renders.

The intended behavior of unity_SpecCube0 is to contain the cubemap for the reflection probe closest to the current renderer, or the skybox cubemap as a fallback in case there are no nearby reflection probes. The skybox is not a renderer at all, and doesn't exist as an object in the scene. Thus it doesn't make sense to ask about its corresponding reflection cubemap.

The reason this "works" when a renderer is added to the scene, is because during the drawcall for this renderer, the unity_SpecCube0 uniform will be set to whatever cubemap is relevant to that renderer. This uniform then leaks to subsequent drawcalls (including the drawcall for the skybox on the next frame) as a side effect. If you add some reflection probes and renderers to the scene, you will observe inconsistent results - the unity_SpecCube0 uniform read in the skybox shader will always correspond to whichever renderer was rendered last in the previous frame. This is essentially random behavior.

In summary, uniforms like unity_SpecCube0, unity_SHAr, etc. are only meant to be used in shaders applied directly to a renderer in the scene. When used elsewhere, they are in an unspecified state. If your usecase demands feeding a cubemap to your skybox material, you can set it manually using Material.SetTexture on RenderSettings.skybox, or by using Shader.SetGlobalTexture.