I'm 100% certain that the primary reason boils down to "we don't have the rights to all of the source code, and we don't want to deal with any of the options for moving forward."
As sibling comment points out, a lot of console SDKs are pretty heavy in the "this code must never be open-sourced" space (hell, even talking about what's in them can run afoul of NDAs). But it goes beyond that. Building assets might require a suite of proprietary tools and custom extensions for those tools, where your ability to release those extensions may be legally unsound. Many games will have several libraries, not all of them open source (and some of them probably under pretty strict don't-even-think-about-asking-us rules--can't imagine many anticheat or DRM packages are going to say yes to allowing source to be released).
If the company doesn't have the rights to large chunks of the source code, their options boil down to:
* Release just the bits they have the rights to, which isn't going to be compilable. And hope that nobody complains about residual references to their code in the released stuff (litigation risk!).
* Spend time going through the code to sanitize references to unreleasable code, but still just release the not-working code drop.
* Do the above, but also replace the unreleasable bits with working releasable bits.
* Do nothing.
One option involves no work and no risk. One option involves minimal work but incorporates small-to-medium risk, but also sacrifices much of the benefits of open-sourcing (there is likely to be community blowback if the product is unusable!). Two options involve a lot more work to mitigate the risk.
It's going to be rare to find the corporation that's going to go for the no work/no risk route. If you want to change that, the best way is to create legal mechanisms to make the no work option much higher risk than the other options.