A billion years ago this code was added to CreateInvDeviceZToWorldZTransform() in SceneView.cpp
// Subtract a tiny number to avoid divide by 0 errors in the shader when a very far distance is decided from the depth buffer.
		// This fixes fog not being applied to the black background in the editor.
		SubtractValue -= 0.00000001f;
This makes it to where the View_InvDeviceZToWorldZTransform used for the calculations looks like this in the shader
View_InvDeviceZToWorldZTransform	{ 0, 0, 0.1, -1e-08 }	float4
        C0	0	float
        C1	0	float
        C2	0.1	float
        C3	-1e-08	float
The decompiled shader code for the Material above (thank you PIX, r.shader.symbols=1, r.shaders.optimize=0, r.Shaders.RemoveDeadCode=1) looks like this (with bits stripped out)
// Get the pixel depth for input A
        float Local1 = GetPixelDepth(Parameters);
	float Local2 =   Local1 .r;
	// Get the depth for input B from the custom depth texture which defaults to all zeros)
	float4 Local3 = SceneTextureLookup(GetDefaultSceneTextureUV(Parameters, 13), 13, false);
	// Make opaque where the scene texture depth is greater than the pixel depth
	float Local4 =  select_internal( (  Local2  >= Local3.rgba.r) , 0.00000000f , 1.00000000f );
        PixelMaterialInputs.Opacity = Local4;
SceneTextureLookup() calls CalcSceneCustomDepth() which looks like this
float CalcSceneCustomDepth(float2 ScreenUV)
{
	return ConvertFromDeviceZ(Texture2DSampleLevel(TranslucentBasePass_SceneTextures_CustomDepthTexture, TranslucentBasePass_SceneTextures_PointClampSampler, ScreenUV, 0).r);
}
And ConvertFromDeviceZ is where View_InvDeviceZToWorldZTransform is used
float ConvertFromDeviceZ(float DeviceZ)
{
	return DeviceZ * View_InvDeviceZToWorldZTransform[0] + View_InvDeviceZToWorldZTransform[1] + 1.0f / (DeviceZ * View_InvDeviceZToWorldZTransform[2] - View_InvDeviceZToWorldZTransform[3]);
}
And that is why you don’t get the full depth range (fog and potential divide by zero errors).
If you comment out the code in CreateInvDeviceZToWorldZTransform() in SceneView.cpp that modifies SubtractValue and recompile, then you won’t have this limitation and will see the entire red cube in all its glory.
However, I’m not advocating you do that just yet, there’s likely a better way ™ that uses the large world coordinates functionality to achieve what you want and I’m consulting with my colleagues on that.