Why is it said that WinRT replaces the Windows API
This has kind of changed, recently due to a couple reasons, but here's the rundown of why you want to use WinRT over Win32 in current Windows application development (circa 2017):
- WinRT is leveraged by UWP apps
- Win32 apps can be converted into UWP apps using the Desktop Bridge
- Windows 10 S requires all apps to go through the Windows Store
Ergo, using WinRT will invoke less time spent converting projects and code for the new Windows 10 S Store-only application paradigm.
In regards to WinRT vs. Win32API vs. .NET, both .NET and WinRT are partially built with Win32; IIRC, they use subsets of it. At least that's what was communicated back in 2012 from ArsTechnica in Peter Bright's article, "Turning to the past to power Windows’ future: An in-depth look at WinRT". That's where this stack chart comes from, or at least it was used there:
I'm not sure if it's often said that the Windows Runtime (WinRT) API replaces the Win32 API. It's not something Microsoft is saying. In many ways WinRT tries to learn from the failure of the .NET Framework to replace the Win32 API. That includes Microsoft not trying to push WinRT as a replacement, but merely a new way of doing things.
There isn't actually much of a reason why the applications you mentioned couldn't be be implemented using the WinRT API. The new API includes a lot of the functionality of the old. You can write WinRT applications in C++ and the resulting applications are native executables, not managed ones. It's even possible to use a subset of the Win32 APIs.
While Adobe has little to gain by porting its applications to WinRT, expect Microsoft to do so. They rewrote most of Visual Studio to use the .NET framework. If anything the WinRT API makes it practical to implement much more of it the new environment.