An application being sandboxed has nothing to do with whether it has access to Live APIs or not. We had a stack of games all accessing Live APIs last gen, it was called for GFWL.
When UWAs release on the Xbox One, then you'll have your evidence that UWAs are not suitable for traditional Xbox One games, because the games you'll see released there as UWAs are going to be XBLA / XBLIG level titles.
The applications being sandboxed or not is unimportant. This isn't a discussion on "can it connect to Live"... there are webpages that can do that, and a sandboxed Win32 application is hardly going to automatically become mobile-ready. This is a discussion about platform commonalities between devices, much like how even before UWAs a Windows Phone port of an app made it very likely for a Windows 8 version of an app to also exist, because the work porting between the two is dramatically smaller than the work involved in getting the app from Android of iOS to either Windows platform in the first place.
What we know of the Xbox One's implementation of Windows Apps, is that there are apps that can run alongside an Xbox game. These apps live in an area partitioned off from the rest of the system that's running the main game, and are limited in the resources they can draw from the console (for obvious reasons). So if we ignore the 3rd intermediary OS that apparently is responsible for putting it all together, we're left with two areas of the system that we'll call game and app. Game gets 90% of the system resources (give or take) and app gets the remaining 10%. Now, here's the bit that's pretty important. If I create a super simple game like Threes, that can well enough live within the app partition of the console (and can be snapped, suspended etc whilst Halo 5 is being played)... what would be required to then have that
exact same game run in the game partition? Would this require the equivalent of a full port to a completely new platform, or would it be mostly the same code, but running in the less restricted environment? The latter seems far more logical, as the former suggests that other than Win32 and UWP (extended from WinRT), MS has created a third and completely unrelated development platform for Xbox One specific games. Considering the push for platform unification predates both the Xbox One and Windows 10, that they advised developers waiting for ID@XBOX (which would include those creating gaming experiences that would live firmly in the 'game' partition of the system) that developing for the similar Windows 8 (WinRT) platform was the best way to get a headstart on Xbox One development, and that their Windows development platform is evidently capable to running software that is demanding on the hardware (such as RoTR, Fable Legends, Quantum Break, etc)... what purpose would there be to use a completely separate implementation between the two sections? Assuming they're
not completely different implementations... that would mean that the reverse also makes a lot of sense... that an app written for the Xbox's game partition would transfer painlessly to the app partition, were it not for the resource limitation placed upon them. This particular scenario would then logically be... a UWA running on Windows 10.
I find it pretty amusing actually, how when discussing Windows 10 applications, people are so quick to proclaim that they essentially "turn your PC into a console"... but the despite MS' claims that the unified platform makes ports between the two easier (and specifically uses real Xbox
games as examples, not just something like Netflix), the idea that the platform they built for this purpose on Windows at all resembles the platform they built for their console is completely unacceptable... and the deduction to be made is that they're simply lying, and nothing is any easier than it's ever been previously.
Why would they choose for it not to be?, is the question that you should really be asking yourself here.
