Wow, the comments make it seem like this has anything to do with Windows UWP platform. So much misunderstanding here and the OP is even quite a bit misleading.
1) UWP is the branding behind many technologies, but most commonly thought of as the containerization and sandboxed subset of the Win32 API available to the application. This would have been great had it not poorly abstracted a lot of very common I/O APIs. The first version didn't allow normal socket API, you had to use the HTTP or some janky intern's first project streaming socket API.
Another annoyance, none of the file system APIs that had 20 years of software written around worked anymore, instead you had to rewrite on top of a completely different API that was in no way compatible with the previous API set.
Contrast that with Apple's iOS sandbox story, the entire Foundation and Core Foundation library, including all of the expected POSIX (BSD variant) code continued to be available. Developers early in the platform's life could take their previous work and just recompile it for the phone and build a new mobile UI on top of it.
iOS in the very beginning had its fans but also only one or two developers who were eager to convince management they should write software for it. Whereas Microsoft's vision for requiring you to rewrite the majority of your software from the bottom to the top on this container system meant serious up front investment. For a new platform, the chicken and egg problem meant even Microsoft couldn't justify the cost.
2) Over time Microsoft has changed course and re-enabled a lot of the Win32 restrictions they engineered in place to write containerized applications. It's still not 100% there and I think they probably gave up trying to make it work. Instead they decided just to allow Win32 software in its entirety to run on the sandbox through another marketing platform, "Desktop Bridge." This brought a flood of 3rd party apps to the Microsoft Store since it was finally easy to port software over.
It's definitely not the same though, because UI (xaml) is still locked behind the container system. Yet all the work the Windows UI team is investing in is in this new container XAML UI. It's a nice UI surface, because you get a lot for free now, High-DPI and scaling just works and animations that don't look like garbage.
Unfortunately you cannot have both. You cannot have the newest UI framework and continue to have access to the entire platform API in a sandbox. Microsoft enabled a bunch of super hacks to try to allow you to write containerized UI but it's not straightforward and you're better off picking one platform or the other.
..
So thiiiiis is where I see the demise of Mobile Office. Desktop Bridge will allow Win32 Office to continue to work on all tablets and desktops. Even the ARM variant will run them, and Win32 Office already has an ARM port, so it's not likely that will change. They won't get access to the containerized UI, but Office has always been its on custom UI beast. So I doubt they need to suffer the limitations of the containerized API subset, get full access in the Win32 API and unify the teams.
It makes perfect sense to me and if I were the PMs in charge of this, I would have done this a while ago.