"True" white balance for a digital camera is multipliers for R, G and B. If you have the exact same multipliers in two software you get the exact same white balance. Few softwares allow you to set the multipliers directly though, as it would be a too technical interface.
Instead you usually set white balance with "temperature and tint". Some raw converters convert those to multipliers and store those, and some, like ACR, store the temperature and tint rather than multipliers. The problem is that there is no standard formula to convert multipliers to temp/tint, so 5000/+10 in one raw converter may not be the same as 5000/+10 in another.
With ACR it's even "worse", as temp/tint is derived using the color matrices in the DNG profile. So if you change profile the temp/tint derivation will change, as color matrices are not exactly the same. As ACR store temp/tint rather than the multipliers when you change profile the multipliers change, but temp/tint stays the same. However, if you have white balance "As Shot" ACR actually use the *multipliers* stored in the raw file, and thus when you change profile white balance stays the same, but temp/tint change. And of course if you use a wb picker the white balance will be set after that patch, but if you change profile after that, the wb is set from temp/tint and you will have a shift so you need to use the wb picker again.
Perhaps one would think as the profile is calculated for the same camera the color matrices would be "close enough" that this would not be an issue. But cameras are far from exact color temperature measurement devices, and algorithms of how to calculate the color matrices differ between software so you can easily get a few hundred degrees difference, and certainly a visible difference.
A work-around for ACR users is to copy the ACR color matrices into DCamProf profiles, which you can do using the -m parameter to make-dcp command.
As the color matrices are only used for temp/tint calculation and not the actual color rendering (forward matrices are used for that) you won't hurt color.
If you ask me I think it would have been better design by Adobe if they'd always store the multipliers instead so changing profile never could cause a white balance shift, but it is the way it is.
To make sure RT and ACR renders the same you need to make a DNG and let RT use that, as black levels and white levels may differ a bit between ACR's and RT's raw format translation. I don't think it should be an issue for the NEF though, but it can be good to do as a precaution. Black render we have already discussed, then there's the output profile and clip handling which you have noted.
I still think the difference in color of the blue sky is a bit strange, and the flat colors of the rock and the closest door doesn't seem right, it's as if the ACR screenshot doesn't reach to full clipping. I would suspect some issue with output profile. Note the yellowy detail in the center of the bottom edge of the image, it's clearly clipped in RT, but just flat gray in ACR.
Also note that when making screenshots the use or not use of display profile can cause unexpected results.
I haven't done any recent comparison between ACR and RT, but my memory tells me that they should be much closer than your images show when the same normally exposed DNG is used with the same DCP (with blackrender=none flag), using the same white balance, and the same output profile.
